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 <[email protected]> > On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider < > [email protected] > > 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<[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> > >>> > >>> > > > > -- > > > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > Talend Application Integration Division http://www.talend.com > > > > > > > -- > Toni Menzel Source <http://tonimenzel.com> >
