I'm also +1 on this; the overhead should be marginal compared to the
advantages.
Kind regards,
Andreas
On Mon 06 Feb 2012 06:30:55 PM CET, Jamie G. wrote:
+1 sounds good to me.
Cheers,
Jamie
On Mon, Feb 6, 2012 at 12:58 PM, Christian Schneider
<[email protected]> wrote:
+1
Makes sense to me to make the system repo look like a real maven repo.
Christian
Am 06.02.2012 16:33, schrieb Jean-Baptiste Onofré:
Hi guys,
I'm back to you with a proposal.
Currently, as the Karaf system repo doesn't contain the artifacts
metadata, without this metadata, aether always download the artifact from
the "remote" repo.
If we have the metadata in the Karaf system repo, if the "local" metadata
are newer than the remote ones, aether won't download the artifact from the
remote repo. If the metadata is newer on the remote repo, aether will
download the metadata and the artifact from the remote.
It's the normal behavior, the one expected by aether.
So basically, including metadata in the Karaf system repo fixes our
problem and we have a consistent behavior.
Aether also provides an API (a kind of installArtifact() method) which
generate the artifact metadata.
So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
Aether API. The purpose is to have the metadata in the Karaf system repo.
Pros:
- Karaf system repo is real Maven3 compliant repository
- We respect a Maven3 style artifact lifecycle
Cons:
- We have a small overhead (in terms of space usage) in the system repo
(metadata properties, pom xml, etc)
WDYT ?
Regards
JB
On 02/02/2012 10:04 AM, Jean-Baptiste Onofré wrote:
Hi all,
On Karaf trunk (3.0), we currently from an issue around artifact
resolution (due to pax-url/aether).
It's something that David, Achim and I are aware, but I would like to
warn and inform everyone (to avoid unpredictable behaviors ;)).
1/ SNAPSHOT resolution
Currently, the system repo doesn't contain Maven metadata, sha1, Maven
properties files. So, Aether always downloads the SNAPSHOT from Central
and overrides the file locally in system repo.
For instance, if you change the Karaf features file locally in the
build, the generated distribution will embed the updated file, but this
file will be overrided (when you perform feature:list or
feature:list-url) by the one on snapshot remote repo.
A "simple" workaround is to deploy the feature file (mvn deploy), but
it's really ugly.
2/ Karaf bootstrap time
A side effect is that Karaf 3.0 is really long to start and bootstrap,
because Karaf checkes for update for each bundles/artifacts in system
repo.
I evaluated that Karaf 3 takes 10 more times than Karaf 2 to start
(depending of the network connection).
I consider it as a major issue, and I'm focusing on it (on both Karaf
and Pax URL).
Regards
JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
