On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <be...@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 <t...@okidokiteam.com>
>
> > On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider <
> > ch...@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<t...@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<t...@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é<
> j...@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é
> > >>>>> jbono...@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>
