karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Mon, 06 Feb 2012 15:48:38 GMT
+1 (non binding *g*)

On Mon, Feb 6, 2012 at 4:41 PM, Achim Nierbeck <bcanhome@googlemail.com>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é <jb@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é
> > jbonofre@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/>
>



-- 
Toni Menzel Source <http://tonimenzel.com>

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