Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of seijoed@gmail.com designates
 209.85.210.169 as permitted sender)
Subject: Re: Features
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Johan Edstrom <seijoed@gmail.com>
In-Reply-To: <1391825.dAi26vcxBV@dilbert.dankulp.com>
Date: Wed, 19 Oct 2011 10:11:32 -0600
Cc: dev@karaf.apache.org,
 Gert Vanthienen <gert.vanthienen@gmail.com>,
 dev@cxf.apache.org,
 dev@servicemix.apache.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <31681253-8E6E-491D-B940-CCD89C1414CC@gmail.com>
References: <74259838-5622-4AB1-ABC8-58258D944BBC@gmail.com>
 <2028850.yX0ArTDIk9@dilbert.dankulp.com>
 <CACAPQZ5aa6Hr0PvkeU81RKDFLXGxF2oLc_bGjU2+4wmk1sU7iA@mail.gmail.com>
 <1391825.dAi26vcxBV@dilbert.dankulp.com>
To: dev@camel.apache.org

Well I'm glad I'm not the only one.
The disparity between camel and cxf was the biggest issue, since camel
overrides the cxf feature with other versions.

In the customer case I resolved it with using karaf features + camel =
features,=20
that at least got the cxf bundles in cleanly - but with an older neethi =
version.

/je
On Oct 19, 2011, at 8:52 AM, Daniel Kulp wrote:

> On Wednesday, October 19, 2011 10:13:23 AM Gert Vanthienen wrote:
>> L.S.,
>>=20
>> Yeah, we are moving in the right direction there, so nice work! One =
thing I
>> bumped into while doing a bit of a refactoring of the servicemix =
features
>> codebase, was the fact that some features descriptors contain a =
reference to
>> another one, e.g. the camel features descriptor refers to the cxf =
features
>> descriptor.  While this does ensure that the Camel features =
descriptor is
>> self-contained, it also means that if you combine it with version of =
CXF
>> you now suddenly have all feature definitions twice (which has caused =
some
>> confusion for me when it picked the wrong version, so I'm guessing =
the same
>> thing will happen for users).
>=20
> There is DEFINITELY a bug in the features-maven-plugin around this.  =
JB and I=20
> were chatting about this on Friday and digging into the code.   The =
features=20
> plugin really just has a single Map<String, Feature> to map the =
requested=20
> features.   There isn't any concept of versions of the features to =
resolve,=20
> etc.... In many cases, transitive features can actually override =
features=20
> previously defined, but in other cases they wouldn't.  Etc....   At =
the very=20
> least, that map needs to be something like Map<String, List<Feature>> =
or=20
> similar to allow the various versions of the features to looked up in =
there.  =20
> Ideally, the <features> list in the pom could also be extended to =
allow=20
> versions:
>=20
> <features>
>   <feature>cxf/2.5.0</feature>
>   <features>camel-core/2.8.2</feature>
> ....
>=20
> or similar to make sure the developer can get complete control over =
that=20
> aspect of things.   Just like with maven, transitive deps are great, =
but you=20
> do need to make sure there is a way to override them.
>=20
>=20
> Dan
>=20
>=20
>=20
>> Not really sure what the ideal solution here would be.  Using a =
version
>> range for the mvn: url for the features.xml would be a start, but =
then you
>> end up with Maven version resolution that might not work well in an =
offline
>> situation or may even pick up another version of CXF than the one you
>> intended to use.
>>=20
>> Perhaps we could reimplement this to behave like a pre-requisite =
instead,
>> first looking if there's a feature descriptor installed that matches =
the
>> version range and only then trying to resolve and install it?
>>=20
>> Regards,
>>=20
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>=20
>> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dkulp@apache.org> =
wrote:
>>> On Friday, October 14, 2011 11:58:26 PM Johan Edstrom wrote:
>>>> Hey,
>>>>=20
>>>> Just poking around in the features, and yes I cross post this -
>>>>=20
>>>> I know there has been work going on with regards to creating a sane
>>>=20
>>> default
>>>=20
>>>> set of features but currently the CXF features in 2.4.2 (I think it
>>>> was) uses spring 3.0.6, the karaf features 3.0.5 and the camel
>>>> features>=20
>>> actually
>>>=20
>>>> copy in cxf with a similar version but the older neethi.
>>>>=20
>>>> If we want these features in a consistent state, should we have a
>>>> master reference?
>>>>=20
>>>> I know this will impact development and agility, but it sure as =
heck
>>>=20
>>> would
>>>=20
>>>> improve stability if we had a solid inheritance chain?
>>>>=20
>>>> I know we also have a bunch of different features in the SMX area,
>>>> would>=20
>>> a
>>>=20
>>>> new features project help? Just asking=85
>>>=20
>>> This is pretty much exactly where JB and I have been going with the
>>> recent changes in the features.  Basically, the projects all STOP
>>> redefining features
>>> like spring and cxf and such.   Instead, they grab those from the
>>> appropriate
>>> place (and using a version range to accommodate updates).
>>>=20
>>> For example:
>>> Karaf 2.2.4 defines all the Spring things.  Thus, neither Camel or =
CXF
>>> define
>>> that anymore.  They just grab spring from there (using "[3,4)" or
>>> similar). Camel 2.8.2 will use the CXF 2.4.3 features directly.  (no
>>> redefines)
>>>=20
>>> If you don't use an obr, we still have issues with different bundle
>>> versions
>>> of various things.   I did sync CXF and Camel as much as possible a
>>> little while ago, but they will likely drift a bit.
>>>=20
>>> Anyway, Karaf 2.2.4, CXF 2.4.3, and Camel 2.8.2 will go a long way =
to
>>> make it
>>> a lot easier and more consistent.
>>>=20
>>> Dan
>>>=20
>>>> Cheers!
>>>=20
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
> --=20
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com