For 2, it's true, the artifacts name will change, etc. But I think it's
the safest way to start the Karaf 3 branch, avoid code duplication, and
have a clean structure.
Regards
JB
On 10/28/2011 02:24 PM, Jamie G. wrote:
Proposal 1: +1
Proposal 2: +1 (if we're going to do any other major refactors then
this is the time to do it - as Ioannis mentioned, this may change
artifact names, etc).
Proposal 3: +1
Proposal 4: +1
On Fri, Oct 28, 2011 at 9:48 AM, Jean-Baptiste Onofré<[email protected]> wrote:
Agree with Gert's proposal.
More than a version range, it's just a check on the URL already registered.
The regex checks the URL without the version.
I will apply this behavior on karaf-2.2.x branch and trunk.
Regards
JB
On 10/28/2011 02:14 PM, Gert Vanthienen wrote:
L.S.,
My suggestion would be to:
- first look for an installed features url that matches the requirement -
if
that already exists, just go ahead and don't install anything else
- if there's no suitable descriptor yet, let pax url mvn resolve that url,
which should give you the highest available inside the range
If there's already a non-matching version installed, I would just stick to
the same routine and have it install a second (other version) features
descriptor as well - after all, one of the benefits of using OSGi is to be
able to use multiple versions of the same thing. I'm not sure how
transitive repository definitions make a difference here, it's actually
there that this feature would be the most useful (at least, from my
perspective in ServiceMix) - if we use cxf and camel and camel use cxf as
well, that's exactly where I would like this solution to make sure that we
don't get duplicate versions installed.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Fri, Oct 28, 2011 at 1:29 PM, Ioannis Canellos<[email protected]>
wrote:
*Feature config attribute:* +1 I consider this really important and is
something that is currently missing.
*Refactoring of maven modules: *0. I am not sure of how the end result
will
be, so I am not sure? I assume that this will change artifact names etc,
and
I am not sure of what the added value will be. I don't object, I just
would
like to hear more about the details to make my mind.
*Making Kar default: *+1.
*Repository version ranges: *+1. There are a lot of times where I felt
that
this was something that was missing. There are a few cases that we need
to
cover.
I assume that when we are talking about something like this:
<repository>mvn:org.cool.product/cool-product/[2,4)/xml/features</repository>
*(I will use this as a reference for my questions below)*
a) Which will be the default repository that will be used? I assume
highest
version available.
b) How will we treat cases were ranges are incompatible? Install both
versions?
c) How should we handle transitive repositories?
d) Will we have some functionality that will try to identify the repo
version to use depending on the artifacts we already have installed?
--
*Ioannis Canellos*
*
FuseSource<http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf<http://karaf.apache.org/> Committer& PMC
Apache ServiceMix<http://servicemix.apache.org/> Committer
Apache Gora<http://incubator.apache.org/gora/> Committer
*
--
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
