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 >
