karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Idea: Allow users to patch feature files
Date Tue, 26 Feb 2013 16:59:13 GMT
And so, if it cleans up the data folder and restart Karaf, all patches 
will be lost.

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