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 >
