karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Idea: Allow users to patch feature files
Date Tue, 26 Feb 2013 20:31:55 GMT
I think the big problem with replacing files in the system repo is that 
you do not see that they are changed. So someone looking at the files 
and versions thinks they are unchanged.
This is why I think a patch would help to clearly show what is 
"enhanced". A simpler way to reach this goal may be to simply create a 
system_patched repo that is prefered in resolution and only contains
the changed files.

I could also imagine a similar feature to patch bundle Manifests. So if 
you specify the mvn url of a bundle you could tweak the imports or 
similar. I think this may perhaps already be possible by patching the
feature file and using wrap: with parameters on existing bundles.

Christian

Am 26.02.2013 17:34, schrieb Jean-Baptiste Onofré:
> 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.
>
> 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
>>
>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message