karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Tue, 07 Feb 2012 09:09:33 GMT
It makes sense to me!
+1


On 7 Φεβ 2012, at 7:13 π.μ., Andreas Pieber wrote:

> 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
>> <chris@die-schneider.net>  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
>>> 

Ioannis Canellos
FuseSource

Blog: http://iocanel.blogspot.com
Apache Karaf Committer & PMC
Apache Camel Committer
Apache ServiceMix  Committer
Apache Gora Committer
Apache DirectMemory Committer


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