karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: Idea: Allow users to patch feature files
Date Tue, 26 Feb 2013 19:16:20 GMT
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
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

Wiadomość napisana przez Chris Geer <chris@cxtsoftware.com> w dniu 26 lut 2013, o
godz. 12:29:

> On Tue, Feb 26, 2013 at 10:09 AM, Jean-Baptiste Onofré <jb@nanthrax.net>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é <jb@nanthrax.net>
>>> 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é <jb@nanthrax.net>
>>>>> 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 <
>>>>>>> chris@die-schneider.net> 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é
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>> 
>>>>> 
>>>>> 
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>> 
>>> 
>>> 
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 


Mime
View raw message