+1 (non binding *g*) On Mon, Feb 6, 2012 at 4:41 PM, Achim Nierbeck <[email protected]>wrote:
> 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é <[email protected]> > > > 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é > > [email protected] > > 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/> > -- Toni Menzel Source <http://tonimenzel.com>
