karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@gmail.com>
Subject Re: Features
Date Wed, 19 Oct 2011 08:13:23 GMT

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).

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.

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?


Gert Vanthienen
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/

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,
> >
> > Just poking around in the features, and yes I cross post this -
> >
> > I know there has been work going on with regards to creating a sane
> default
> > 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
> actually
> > copy in cxf with a similar version but the older neethi.
> >
> > If we want these features in a consistent state, should we have a master
> > reference?
> >
> > I know this will impact development and agility, but it sure as heck
> would
> > improve stability if we had a solid inheritance chain?
> >
> > I know we also have a bunch of different features in the SMX area, would
> a
> > new features project help? Just asking…
> 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).
> 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)
> 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.
> 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.
> Dan
> >
> >
> > Cheers!
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message