karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Idea: Allow users to patch feature files
Date Tue, 26 Feb 2013 20:11:02 GMT
Shouldn't the use of version ranges for features + OBR somehow solves the
problem ?


On Tue, Feb 26, 2013 at 8:21 PM, Daniel Kulp <dkulp@apache.org> wrote:

>
> On Feb 26, 2013, at 11:16 AM, Łukasz Dywicki <luke@code-house.org> wrote:
>
> > 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.
>
> How do you propose to create  a ServiceMix release that uses Camel 2.10.4
> (latest release) and CXF 2.7.3 (latest release) without some sort of
> mapping of features file patching or similar?   It's the exact same problem
> for ServiceMix.   We're trying to find a solution that is a bit more
> generic.
>
> Dan
>
>
> >
> > 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
> >>>
> >
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message