I like the idea of mapping uris. It is simpler than patching and
achieves the same effect.
My current problem was that I had to do some changes to the camel karaf
commands. So one rule to replace the camel 2.10.2 version of the bundle
with the 2.10.4 version would have activated this in
a user installation. This sounds really good.
Christian
Am 26.02.2013 18:09, schrieb Jean-Baptiste Onofré:
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 ?
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
