Yup, regex support definitely makes sense.
Regards
JB
On 02/26/2013 06:15 PM, Daniel Kulp wrote:
On Feb 26, 2013, at 12:09 PM, 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 ?
Yea. Exactly that. Thanks for distilling my random thoughts down into
something workable.
I'd SUGGEST also making the source URL's a regex of some sort:
mvn:foo/bar/1.*/xml/features=mvn:myfoo/mybar/1.1/xml/features
or similar. People could use exact versions/url's, but a regex just makes it
a bit more flexible. Probably could even do the group expansions:
mvn:org.apache.cxf/(.*)/2.6.5=mvn:org.apache.cxf/\1/2.6.6
:-)
Dan
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
