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é <j...@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é > jbono...@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/>
