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 >> <ch...@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
