karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Thu, 02 Feb 2012 21:03:59 GMT
Yes, of course there are uses for "online" mode. I hope noone believes that
I want to remove that possibility. It can even be the default as long as
there are ways to "lock down" Karaf. It's both a matter of "security"
(don't use unknown or untested code in production) and of "convenience"
(verify in development that the installation includes everything needed).

@Toni

>What you also can do is using a local, shipped with karaf maven repository
>and set that as the only one (already possible)

I wasn't aware of this. Can you enlighten me about how this is done?

/Bengt

2012/2/2 Toni Menzel <toni@okidokiteam.com>

> On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider <
> chris@die-schneider.net
> > wrote:
>
> > I also think the offline feature is really important. At talend for
> > example we want
> > to make sure our distribution works when offline so this setting could
> > also be useful for tests.
> >
> > On the other hand I would not really say that downloading artifacts on
> > demand would never happen in production.
> > I can very well imagine deploying a very small container and then
> > downloading libs and custom applications from
> > a company maven repo. Of course this is different from downloading from
> > the internet but from the karaf point of view it
> > is not an offline mode.
> >
>
> correct!
> And when you think about cloud deployment, or at least a clustered setup,
> you'd be thankful for one central source.  All karaf instances (technically
> "naked" would take their artifacts from there.
> If you want it more sophisticated (e.g. a push approach), you'd use Apache
> ACE perhaps (inside Karaf). In the long run i could see some kind of deeper
> integration of the two projects for initial provisioning (say, Karaf has
> just the bare bone container and bootstrapping stuff, everything else comes
> from an ACE Repository.
> Just an idea so far..
>
>
> >
> > Christian
> >
> > Am 02.02.2012 19:24, schrieb Bengt Rodehav:
> >
> >  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?
> >>
> >> *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.
> >>
> >>
> >> /Bengt
> >>
> >> 2012/2/2 Toni Menzel<toni@okidokiteam.com>
> >>
> >>  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<toni@okidokiteam.com>
> >>>  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é<jb@nanthrax.net
> >>>> 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
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Toni Menzel Source<http://tonimenzel.com>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Toni Menzel Source<http://tonimenzel.com>
> >>>
> >>>
> >
> > --
> >
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >
> >
>
>
> --
> Toni Menzel Source <http://tonimenzel.com>
>

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