I think ServiceMix is just an example of this use case, but end users could have it too with other components.
If we can have version ranges on feature dependencies, so that the features service won't install a dependant version if a higher compatible one is already installed, it would certainly help. If features are installed in batch, the service should be able to select a single feature that solves the constraints. I think that would solve the problem in an easier way. That maybe does not provide a solution for all use cases expressed here, but I think that would fix the need to change the dependencies on features. On Tue, Feb 26, 2013 at 9:14 PM, Łukasz Dywicki <[email protected]> wrote: > Most of you work on Camel and CXF so I see no problem in coordinating > versions used in both places even with different release schedules. > ServiceMix is umbrella project so SMX commiters should take care about > choosing proper versions of CXF/Camel and ActiveMQ at Apache. That is what > I always thinking about SMX. All projects we have must are compatible at > some point. I don't expect that somebody will run Camel 2.11 together with > CXF 2.4 and I don't think that anybody will support that. > That thing may be done for sure using minor releases. If you don't mean > you may create integration-pom shared between CXF and Camel to avoid > version race. > > Kind regards, > Łukasz Dywicki > -- > [email protected] > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > Wiadomość napisana przez Daniel Kulp <[email protected]> w dniu 26 lut > 2013, o godz. 14:21: > > > > > 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/
