I think even less so if SMX is kickstarted to remove old stuff... :) On Feb 26, 2013, at 12:45 PM, Jean-Baptiste Onofré <[email protected]> wrote:
> Hi Lukasz, > > I don't think it's valid as ServiceMix applied patches in the past to work > together with Camel, CXF, ActiveMQ, etc ;) > So the same "problem" is present in ServiceMix. > > Regards > JB > > On 02/26/2013 08:16 PM, Łukasz Dywicki wrote: >> 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 >>>> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
