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 Thu, 02 Feb 2012 22:12:55 GMT
Please do, time to fix misbehaviors in Pax URL Aether..

On Thu, Feb 2, 2012 at 10:58 PM, Bengt Rodehav <bengt@rodehav.com> wrote:

> I have been experimenting with the config.properties  regarding this before
> but I remember having problems preventing the normal maven way of
> resolving. I'll take a look at this again.
>
> /Bengt
>
> 2012/2/2 Toni Menzel <toni@okidokiteam.com>
>
> > On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <bengt@rodehav.com>
> wrote:
> >
> > > 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?
> > >
> >
> > Well, you can always set the repositories in Pax URL via System-, Bundle
> > and/or directly inside the URL. Not really sure what the standards do
> look
> > like in Karaf, but i bet its set in a config properties file. There you'd
> > set repositories to some local, relative folder.
> > Of cause, some initial routine needs to create/unpack that repository (it
> > will look like you .m2/repositories e.g.) initially.
> > Or you ship that in the standard karaf.zip.
> >
> > Hope that is clear?
> >
> >
> > >
> > > /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>
> > > >
> > >
> >
> >
> >
> > --
> > Toni Menzel Source <http://tonimenzel.com>
> >
>



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

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