Guys, I don't think going in 'mapping direction' is good. The scenario you have is really case with version race between CXF and Camel releases. I want mark here, that we have an project to solve problem without complicating Karaf - it's called ServiceMix. ;-) OBR resolver should avoid some of problems you pointed. I think in your case you may publish just updated feature file for things you want to have.
Cheers, Łukasz Dywicki -- [email protected] Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Chris Geer <[email protected]> w dniu 26 lut 2013, o godz. 12:29: > On Tue, Feb 26, 2013 at 10:09 AM, Jean-Baptiste Onofré > <[email protected]>wrote: > >> OK, after discussing with Dan, I got a better understanding. >> >> The purpose is not to have a "patch". The purpose is to have a mapping of >> URL (ALL URL, feature, bundle, config, or whatever). >> >> Basically, it means that we can have a cfg file in etc, let say >> etc/org.ops4j.pax.url.map.cfg containing: >> >> # feature XML >> mvn:foo/bar/1.0/xml/features=**mvn:myfoo/mybar/1.1/xml/**features >> # bundle >> mvn:group/bundleA/1.0=mvn:**group/bundleA/1.1 >> # config >> ... >> >> At URL resolution, Pax Url can check the content of the map cfg and use >> the mapped URL. Like this, it allows users to override any kind of >> resources. >> >> I used Pax Url because the URL handling is performed there, and so I think >> the feature should go there. >> >> WDYT ? >> > > Overall I think this will work but I have one concern around the features > commands. I'm concerned that if it's purely a URL mapping that it might be > confusing to people who run things like "feature:info camel" and the > dependency list shows "camel-core 2.10.3" even when 2.10.4 being installed > due to a mapping. It would be better (IMHO) that if there is a mapping, the > feature commands could use that data as well and display what the "new" > dependencies are. I realize this complicates things a bit but it will > reduce confusion long term. > > Best case for "feature:info camel" would be showing something like this. > > Description of camel 2.10.3 feature > ---------------------------------------------------------------- > Feature has no configuration > Feature has no configuration files > Feature depends on: > camel-core 2.10.3 (mapped to camel-core 2.10.4) > camel-spring 2.10.3 > camel-blueprint 2.10.3 (mapped to camel-blueprint 2.10.5-SNAPHOT) > Feature has no bundles. > > Bottom line: URL mapping sounds good but I think more than Pax-URL needs to > be aware of it to reduce confusion. > > Chris > >> >> Regards >> JB >> >> >> On 02/26/2013 05:57 PM, Daniel Kulp wrote: >> >>> >>> On Feb 26, 2013, at 11:34 AM, Jean-Baptiste Onofré <[email protected]> >>> wrote: >>> >>> Catcha. >>>> >>>> I think that if we update the feature XML (including the URL of >>>> bundles), it works with a simple URL refresh on the features repositories. >>>> >>>> My point is: if the user override the features XML in the system repo, >>>> it already works. So we can apply diff + patch -p0 directly on the features >>>> XMLs. >>>> >>> >>> The problem with this is that if the user then does: >>> >>> features:chooseurl foosnarf 2.5 >>> >>> and foosnarf also uses an older version, they still get the older >>> version. This requires the user to to patch a BUNCH of features.xml >>> files. I'd definitely prefer something that would allow overriding of >>> information in the system directory (or pulled in), not require changes to >>> stuff in the system directory. >>> >>> Dan >>> >>> >>> >>> >>>> Regards >>>> JB >>>> >>>> On 02/26/2013 05:30 PM, Daniel Kulp wrote: >>>> >>>>> >>>>> On Feb 26, 2013, at 11:14 AM, Jean-Baptiste Onofré <[email protected]> >>>>> wrote: >>>>> >>>>> What is the value comparing to just a URL refresh and bundle refresh ? >>>>>> Not sure to see the point. >>>>>> >>>>> >>>>> Basically, to allow productizations of Karaf to more easily unify >>>>> versions of various libraries. For example, lets suppose the CXF >>>>> features.xml pulls in a particular version of something, lets say WSS4J. >>>>> Camel, because they may run a little behind CXF, may have an older version >>>>> in their features.xml. (forget ranges and forget the obr for second) If >>>>> we could map URL's, we could leave the camel features file alone. There >>>>> are a bunch of bundles that CXF and Camel (and others) have at different >>>>> patch levels. Yes, we can work in the communities to unify some of that, >>>>> but that still leaves the people that are trying to mix and match various >>>>> versions to have some extra headaches. >>>>> >>>>> The other scenario would be that Camel imports the CXF features file. >>>>> Thus, to get Camel to use a new version of CXF requires a patched version >>>>> of the Camel features.xml or you end up with both versions of CXF in the >>>>> features:list. If we could map the URL for the imported features.xml, >>>>> then we could, more simply, prevent these issues. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On 02/26/2013 05:12 PM, Daniel Kulp wrote: >>>>>> >>>>>>> >>>>>>> Could this be even more "generic" and apply to everything loaded via >>>>>>> a URL? Swap the version of "xerces" with this new version. Or use >>>>>>> specs >>>>>>> 2.2 instead of 2.1 or similar. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On Feb 26, 2013, at 3:46 AM, Christian Schneider < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>>> >>>>>>>> sometimes we have the issue that a feature file of an already >>>>>>>> released project is incorrect. Another similar case is if a small issue >>>>>>>> appears that can be fixed by just patching a single bundle. >>>>>>>> In both cases it is necessary to change an existing feature file to >>>>>>>> make this work without a new release and without making user apps bump >>>>>>>> up >>>>>>>> the dependency to the feature file to the next bugfix release number. >>>>>>>> >>>>>>>> So I thought about a way to patch feature files at runtime. >>>>>>>> >>>>>>>> The idea is to have a config with: >>>>>>>> <mvn url of feature>:<path to patch> >>>>>>>> >>>>>>>> This config would make the feature command apply the patches to the >>>>>>>> named feature files after loading them. So a user could patch their >>>>>>>> feature >>>>>>>> files to quickly fix simple issues. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Christian >>>>>>>> >>>>>>>> -- >>>>>>>> Christian Schneider >>>>>>>> http://www.liquid-reality.de >>>>>>>> >>>>>>>> Open Source Architect >>>>>>>> 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 >>>> >>> >>> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >>
