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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
