Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F55FE9E.6040207@nanthrax.net>
Date: Tue, 06 Mar 2012 13:10:06 +0100
From: =?ISO-8859-1?Q?Jean-Baptiste_Onofr=E9?= <jb@nanthrax.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: dev@karaf.apache.org
Subject: Re: Update on Karaf 3.0.0
References: <4F55E101.9020506@nanthrax.net>
 <4F55FA65.8060101@die-schneider.net>
In-Reply-To: <4F55FA65.8060101@die-schneider.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Christian,

my comments inline:

>> 1/ Bootstrap time and artifacts resolution
>> I fixed the latest issue around pax-url-aether and artifacts
>> resolution on Saturday.
>> Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and
>> install-kar goals) creates or copy the maven-metadata-local.xml.
>> It means that only new SNAPSHOTs will be downloaded from a remote
>> repository.
>> More than easy testing/updating, a good news is that the artifact
>> resolution is largely quicker than before, and so the Karaf bootstrap
>> time is largely better (now the Karaf bootstrap on trunk is equivalent
>> to Karaf 2.2.x).
> I found more bugs / strange behaviour in the current version. The
> immediate problem I had is fixed. So my snapshot of the shell/config is
> used now after I do a full build.
> The problem is that I can not really update my jar in a running karaf.
> Update <bundleid> does not find my new version. dev:watch also does not
> work.
> When I delete the artifact=B4s dir in system and do update karaf loads =
the
> snapshot from the external repo.
>
> So I think the problem is that system is currently used somehat like an
> local repo. Karaf writes downloaded artifacts there. On the other hand
> is is used like a remote repo when
> looking up artifacts.
>
> I think this looks quite broken.

With pax-url-aether, the Karaf system folder is *really* considered like=20
a Maven 3 repo.
Previously with pax-url-mvn, it was a kind of Maven 2 repo without using=20
Maven API.
So the Karaf system folder exactly behaves as your .m2/repository repo.

It means that, in your m2 repo, if you copy a jar file, and the same are=20
present on Central for instance, your jar will be overrided by the=20
remote artifact.
That's why you type mvn install: mvn install goal generates the=20
maven-metadata-local.xml for you to overwrite your jar only if a new one=20
is present on Central.

So Karaf system folder works like this. The karaf-maven-plugin now=20
generates the maven-metadata-local.xml. If you want to install only a=20
jar in the system folder, you have to use:
mvn install:install-file -Dfile=3D... -Durl=3Dfile:/path/to/karaf/system

It's the expected behavior, matching the aether lifecycle.

>
> I will add a jira issue.
>> 3/ Module refactoring
>> Christian provided a patch around config handling.
>> I will refactore it a bit to adopt the same way as feature, system,
>> etc modules (core bundle, management bundle, command bundle).
>> I will take update some others modules in the same way.
>> It should be done tomorrow evening or Thursday mornning.
> Please do not yet refactor this. Let me first commit on trunk. I am
> doing the last tests and will commit today. If you tell me what you wan=
t
> I can also do the refactoring.
> The patch I submitted was for 2.2.x. After a discussion with Achim we
> agreed that we should not change much for 2.2.x and instead just fix th=
e
> bug with delayed updates.
> I will fix this on trunk first and then backport to 2.2.x.

OK let me know when I can refactore.

>
>> 4/ Karaf 3.0.0 branch
>> I plan to cut off the karaf-3.0.x branch over the week end and prepare
>> a first RC.
>>
> When I look in jira I see ~100 open issues for 3.0.0. So I think we are
> far from ready to branch and release a RC.

I think that lot of Jira could be moved to 3.1.
I propose to review this Jira and get back to you with a clear roadmap=20
for 3.0.

I'm really concerned about this feedback because:
- we discussed about the Karaf 3.0 release in December, including a=20
review during the meeting in January. Now we have different point of=20
view that should have been discussed before
- I'm feeling quite the only one really working on trunk, in preparation=20
for 3.0.0. Some of use spent times to fix issues (on assemblies, on=20
features, on Maven plugin, etc), started to implement the features that=20
we discussed during the meeting (sub-shell). No, whereas we decided 2=20
months ago to cut off the branch, we don't have a consensus ? The trunk=20
version is really so bad ? I don't think so, but maybe I'm wrong.

JB, in a frustrated mode ;)
--=20
Jean-Baptiste Onofr=E9
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com