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:48:00 GMT
Agree,

but I think that using:

feature:install url:patch
(where patch could be a URL, mvn, file, whatever)

will result with the same amount of patch scripts.

It remembers me what I proposed: profiles. A profile is exactly to 
create a diff file (on a whole Karaf distribution), and apply this diff 
(patch) on another Karaf distribution.

Don't get me wrong, I think it could be an interesting feature, but I 
wonder the most elegant way to do it.

Regards
JB

On 02/26/2013 05:41 PM, Chris Geer wrote:
> On Tue, Feb 26, 2013 at 9: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.
>>
>
>  From my perspective, a feature like this a great step forward as I seem to
> spend a decent amount of time customizing feature files just as Dan
> described. While I agree that updating the file in the system repo (what I
> do today) works, it's not really very convenient when you are trying to
> synchronize across multiple containers. You wind up with a lot of scripts
> doing changes behind the scenes. It would be much more convenient to be
> able to deploy patch files into Karaf and let the container handle the
> changes appropriately.
>
> Chris
>
>>
>> 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