karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Idea: Allow users to patch feature files
Date Tue, 26 Feb 2013 17:29:48 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message