karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Update on Karaf 3.0.0
Date Tue, 06 Mar 2012 12:10:06 GMT
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´s 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 
a Maven 3 repo.
Previously with pax-url-mvn, it was a kind of Maven 2 repo without using 
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 
present on Central for instance, your jar will be overrided by the 
remote artifact.
That's why you type mvn install: mvn install goal generates the 
maven-metadata-local.xml for you to overwrite your jar only if a new one 
is present on Central.

So Karaf system folder works like this. The karaf-maven-plugin now 
generates the maven-metadata-local.xml. If you want to install only a 
jar in the system folder, you have to use:
mvn install:install-file -Dfile=... -Durl=file:/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 want
> 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 the
> 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 
for 3.0.

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

JB, in a frustrated mode ;)
Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message