On Thu, Feb 2, 2012 at 7:24 PM, Bengt Rodehav <[email protected]> wrote:
> Link URL looks interesting although I would regard them as a complement to
> direct maven resolving.
>
> I'v always considered the maven support in Karaf as a very useful feature.
> Especially during development since Karaf will pick up my newly built
> artifacts directly from my local maven repository. I'm sure it is also
> useful for populating the bundle cache directly from the Internet although
> I would never use that feature in production (I create a custom
> distribution containing everything I need instead).
>
> What I'm trying to say is that I don't want to take away the maven support
> since it's really useful (in development) but I would like to be able to
> control it (in production) so that:
>
> *Priority 1*: I can stop maven from downloading anything from the Internet
> ("offline" mode). This I think must be mandatory for any production system
> - how else do you know what code you are running?
>
That we can do using a switch in mvn resolver, based on.. lets say a
property setting. Must be done in Pax URL. I can add a ticket + do it.
>
> *Priority 2*: I can restrict maven to only use artifacts contained in my
> custom distribution (mainly the system folder). This would stop maven from
> accessing my local maven repo. This would make it easier to verify that my
> custom distribution contains everything before moving to production.
>
What you also can do is using a local, shipped with karaf maven repository
and set that as the only one (already possible)
>
>
> /Bengt
>
> 2012/2/2 Toni Menzel <[email protected]>
>
> > FYI, with "making the link URL handler more clever" i mean probably
> > encoding the Maven coordinates (GAV) into the link url somehow (by
> > convention), so that it allows to fallback to some other handler (aether
> > e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys have
> > an idea?
> >
> > On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel <[email protected]>
> wrote:
> >
> > > One thing you can do is using "link" URLs.
> > > This is implemented in the pax-url-link project and resolves URLs like:
> > > link:classpath:META-INF/links/junit.link to an InputStream that
> contains
> > > text with first line treated as the real URL.
> > > So, for example, if you include a file with content:
> > > mvn:org.junit/junit/4.8.2
> > > in Classpath at location /META-INF/links/junit.link, you will get the
> > > maven resolution.
> > > But you also could have another runtime dependency resolving the
> > > aforementioned link in class path like:
> > > classpath:junit.jar
> > > which then would use an embedded jar.
> > > You see this brings in some indirection into the resolving process.
> > > In Karaf i could think of shipping a "batteries-included" artifact that
> > > includes many frequently used components, another (maybe an
> > enterprise.jar)
> > > that contains another set of embedded batteries.
> > > Good thing is, you never lose the ability to possibly fall back to mvn
> > > resolvers taking down the artifact from outer space (online maven).
> > >
> > > Did you consider this, yet?
> > > Toni
> > >
> > > On Thu, Feb 2, 2012 at 10:04 AM, Jean-Baptiste Onofré <[email protected]
> > >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
> > >>
> > >
> > >
> > >
> > > --
> > > Toni Menzel Source <http://tonimenzel.com>
> > >
> > >
> >
> >
> > --
> > Toni Menzel Source <http://tonimenzel.com>
> >
>
--
Toni Menzel Source <http://tonimenzel.com>
