Hi Lukasz,
I don't think it's valid as ServiceMix applied patches in the past to
work together with Camel, CXF, ActiveMQ, etc ;)
So the same "problem" is present in ServiceMix.
Regards
JB
On 02/26/2013 08:16 PM, Łukasz Dywicki 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.
Cheers,
Łukasz Dywicki
--
[email protected]
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Chris Geer <[email protected]> w dniu 26 lut 2013,
o godz. 12:29:
On Tue, Feb 26, 2013 at 10:09 AM, Jean-Baptiste Onofré <[email protected]>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é <[email protected]>
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é <[email protected]>
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 <
[email protected]> 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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
