karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Mon, 06 Feb 2012 15:41:15 GMT
Hi JB,

+1 from my side, I think the cons of a small overhead can be ignored
compared to the fully functional maven-type repo we have then :)
cause if we don't provide them those artefacts are generated anyways.

regards, Achim

2012/2/6 Jean-Baptiste Onofré <jb@nanthrax.net>

> 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
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message