On Feb 26, 2013, at 12:09 PM, 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 ? Yea. Exactly that. Thanks for distilling my random thoughts down into something workable. I'd SUGGEST also making the source URL's a regex of some sort: mvn:foo/bar/1.*/xml/features=mvn:myfoo/mybar/1.1/xml/features or similar. People could use exact versions/url's, but a regex just makes it a bit more flexible. Probably could even do the group expansions: mvn:org.apache.cxf/(.*)/2.6.5=mvn:org.apache.cxf/\1/2.6.6 :-) Dan > > 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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
