It seems like you are right JB. I did this: On Karaf 2.2.5 I set the property "org.ops4j.pax.url.mvn.repositories" to an empty list. I then renamed a local jar so that it could no longer be found locally. This gave me an error when a feature needing that bundle were to be installed.
Actually I have done this before when using Karaf 1.6.0 but for some reason this configuration had been removed from my custom server... I did notice that (in Karaf 2.2.5) there is also a property called "org.ops4j.pax.url.mvn.useFallbackRepositories" which by default is set to false. If I set it to true, then Karaf will connect to the Internet and download artifact (from some unknown default set of repositories). I also noticed that this option did not exist back in Karaf 1.6.0. So...maybe (I'm guessing now), back in Karaf 1.6.0 when I had set the "org.ops4j.pax.url.mvn.repositories" property to an empty list, perhaps pax-url-mvn still used the fallback repositories? Back then Karaf used version 1.1.2 of pax-url-mvn while in Karaf 2.2.5 version 1.2.8 of pax-url-mvn is used. Just speculating... Anyway, your suggestion works for me although I would rather have an "offline" option if you think it's OK. I think it's a bit tricky to configure pax-url-mvn and it would be good to make the configuration clearer (and also document it a bit better). E g what does the "org.ops4j.pax.url.mvn.disableAether" option actually do and how does the resolution process work? Are we simulating maven artifact resolution or are we actually using maven's own artifact resolution. Thanks for your help JB, /Bengt 2012/2/3 Bengt Rodehav <[email protected]> > OK - I'll verify that, > > /Bengt > > 2012/2/3 Jean-Baptiste Onofré <[email protected]> > >> Hi Bengt, >> >> I don't think that the behaviour changed in any Karaf version. I don't >> think any bug has been fixed around. >> It should work with any Karaf >= 2.2.0 version. >> >> Regards >> JB >> >> >> On 02/03/2012 12:59 PM, Bengt Rodehav wrote: >> >>> Just to clarify, >>> >>> Did this behaviour change in some version of Karaf (2.2.0?)? I mean is >>> this >>> a known bug that has been corrected? >>> >>> /Bengt >>> >>> 2012/2/3 Jean-Baptiste Onofré<[email protected]> >>> >>> Hi Bengt, >>>> >>>> no I mean in any version since 2.2.0: if you remove all repositories in >>>> etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means >>>> that >>>> Karaf will use only artifacts present in the system repo). >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 02/03/2012 09:44 AM, Bengt Rodehav wrote: >>>> >>>> Thanks I appreciate it. >>>>> >>>>> When you say it's already available I guess you mean on trunk - right? >>>>> I >>>>> think the problems I've had was on version 2.2.0 (I haven't tested >>>>> since). >>>>> At that time I don't think removing all repositories helped. There were >>>>> still some default search that was not disabled (possibly to Central). >>>>> Has >>>>> this behaviour changed on trunk? >>>>> >>>>> /Bengt >>>>> >>>>> 2012/2/3 Jean-Baptiste Onofré<[email protected]> >>>>> >>>>> Hi Bengt, >>>>> >>>>>> >>>>>> basically, the "offline" mode is already possible, you just have to >>>>>> remove >>>>>> all repositories in the etc/org.ops4j.pax.url.mvn.cfg. >>>>>> >>>>>> However, I will add a special option in pax-url for that. >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> >>>>>> On 02/02/2012 07:24 PM, Bengt Rodehav 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? >>>>>>> >>>>>>> *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> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> >>>>>> Jean-Baptiste Onofré >>>>>> [email protected] >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>>> >>>>>> >>>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >>> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
