karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Mon, 06 Feb 2012 16:28:02 GMT
+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


Mime
View raw message