+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 >
