Shouldn't the use of version ranges for features + OBR somehow solves the problem ?
On Tue, Feb 26, 2013 at 8:21 PM, Daniel Kulp <[email protected]> wrote: > > On Feb 26, 2013, at 11:16 AM, Łukasz Dywicki <[email protected]> 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. > > How do you propose to create a ServiceMix release that uses Camel 2.10.4 > (latest release) and CXF 2.7.3 (latest release) without some sort of > mapping of features file patching or similar? It's the exact same problem > for ServiceMix. We're trying to find a solution that is a bit more > generic. > > Dan > > > > > > 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 > >>> > > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
