You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Johan Edstrom <se...@gmail.com> on 2011/10/15 07:58:26 UTC
Features
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…
Cheers!
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
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,
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.,
>>
>> 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).
>
> There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
> were chatting about this on Friday and digging into the code. The features
> plugin really just has a single Map<String, Feature> to map the requested
> features. There isn't any concept of versions of the features to resolve,
> etc.... In many cases, transitive features can actually override features
> previously defined, but in other cases they wouldn't. Etc.... At the very
> least, that map needs to be something like Map<String, List<Feature>> or
> similar to allow the various versions of the features to looked up in there.
> Ideally, the <features> list in the pom could also be extended to allow
> versions:
>
> <features>
> <feature>cxf/2.5.0</feature>
> <features>camel-core/2.8.2</feature>
> ....
>
> or similar to make sure the developer can get complete control over that
> aspect of things. Just like with maven, transitive deps are great, but you
> do need to make sure there is a way to override them.
>
>
> Dan
>
>
>
>> 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?
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
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,
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.,
>>
>> 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).
>
> There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
> were chatting about this on Friday and digging into the code. The features
> plugin really just has a single Map<String, Feature> to map the requested
> features. There isn't any concept of versions of the features to resolve,
> etc.... In many cases, transitive features can actually override features
> previously defined, but in other cases they wouldn't. Etc.... At the very
> least, that map needs to be something like Map<String, List<Feature>> or
> similar to allow the various versions of the features to looked up in there.
> Ideally, the <features> list in the pom could also be extended to allow
> versions:
>
> <features>
> <feature>cxf/2.5.0</feature>
> <features>camel-core/2.8.2</feature>
> ....
>
> or similar to make sure the developer can get complete control over that
> aspect of things. Just like with maven, transitive deps are great, but you
> do need to make sure there is a way to override them.
>
>
> Dan
>
>
>
>> 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?
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
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,
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.,
>>
>> 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).
>
> There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
> were chatting about this on Friday and digging into the code. The features
> plugin really just has a single Map<String, Feature> to map the requested
> features. There isn't any concept of versions of the features to resolve,
> etc.... In many cases, transitive features can actually override features
> previously defined, but in other cases they wouldn't. Etc.... At the very
> least, that map needs to be something like Map<String, List<Feature>> or
> similar to allow the various versions of the features to looked up in there.
> Ideally, the <features> list in the pom could also be extended to allow
> versions:
>
> <features>
> <feature>cxf/2.5.0</feature>
> <features>camel-core/2.8.2</feature>
> ....
>
> or similar to make sure the developer can get complete control over that
> aspect of things. Just like with maven, transitive deps are great, but you
> do need to make sure there is a way to override them.
>
>
> Dan
>
>
>
>> 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?
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
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,
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.,
>>
>> 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).
>
> There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
> were chatting about this on Friday and digging into the code. The features
> plugin really just has a single Map<String, Feature> to map the requested
> features. There isn't any concept of versions of the features to resolve,
> etc.... In many cases, transitive features can actually override features
> previously defined, but in other cases they wouldn't. Etc.... At the very
> least, that map needs to be something like Map<String, List<Feature>> or
> similar to allow the various versions of the features to looked up in there.
> Ideally, the <features> list in the pom could also be extended to allow
> versions:
>
> <features>
> <feature>cxf/2.5.0</feature>
> <features>camel-core/2.8.2</feature>
> ....
>
> or similar to make sure the developer can get complete control over that
> aspect of things. Just like with maven, transitive deps are great, but you
> do need to make sure there is a way to override them.
>
>
> Dan
>
>
>
>> 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?
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, October 19, 2011 10:13:23 AM Gert Vanthienen wrote:
> L.S.,
>
> 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).
There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
were chatting about this on Friday and digging into the code. The features
plugin really just has a single Map<String, Feature> to map the requested
features. There isn't any concept of versions of the features to resolve,
etc.... In many cases, transitive features can actually override features
previously defined, but in other cases they wouldn't. Etc.... At the very
least, that map needs to be something like Map<String, List<Feature>> or
similar to allow the various versions of the features to looked up in there.
Ideally, the <features> list in the pom could also be extended to allow
versions:
<features>
<feature>cxf/2.5.0</feature>
<features>camel-core/2.8.2</feature>
....
or similar to make sure the developer can get complete control over that
aspect of things. Just like with maven, transitive deps are great, but you
do need to make sure there is a way to override them.
Dan
> 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?
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, October 19, 2011 10:13:23 AM Gert Vanthienen wrote:
> L.S.,
>
> 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).
There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
were chatting about this on Friday and digging into the code. The features
plugin really just has a single Map<String, Feature> to map the requested
features. There isn't any concept of versions of the features to resolve,
etc.... In many cases, transitive features can actually override features
previously defined, but in other cases they wouldn't. Etc.... At the very
least, that map needs to be something like Map<String, List<Feature>> or
similar to allow the various versions of the features to looked up in there.
Ideally, the <features> list in the pom could also be extended to allow
versions:
<features>
<feature>cxf/2.5.0</feature>
<features>camel-core/2.8.2</feature>
....
or similar to make sure the developer can get complete control over that
aspect of things. Just like with maven, transitive deps are great, but you
do need to make sure there is a way to override them.
Dan
> 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?
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, October 19, 2011 10:13:23 AM Gert Vanthienen wrote:
> L.S.,
>
> 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).
There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
were chatting about this on Friday and digging into the code. The features
plugin really just has a single Map<String, Feature> to map the requested
features. There isn't any concept of versions of the features to resolve,
etc.... In many cases, transitive features can actually override features
previously defined, but in other cases they wouldn't. Etc.... At the very
least, that map needs to be something like Map<String, List<Feature>> or
similar to allow the various versions of the features to looked up in there.
Ideally, the <features> list in the pom could also be extended to allow
versions:
<features>
<feature>cxf/2.5.0</feature>
<features>camel-core/2.8.2</feature>
....
or similar to make sure the developer can get complete control over that
aspect of things. Just like with maven, transitive deps are great, but you
do need to make sure there is a way to override them.
Dan
> 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?
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, October 19, 2011 10:13:23 AM Gert Vanthienen wrote:
> L.S.,
>
> 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).
There is DEFINITELY a bug in the features-maven-plugin around this. JB and I
were chatting about this on Friday and digging into the code. The features
plugin really just has a single Map<String, Feature> to map the requested
features. There isn't any concept of versions of the features to resolve,
etc.... In many cases, transitive features can actually override features
previously defined, but in other cases they wouldn't. Etc.... At the very
least, that map needs to be something like Map<String, List<Feature>> or
similar to allow the various versions of the features to looked up in there.
Ideally, the <features> list in the pom could also be extended to allow
versions:
<features>
<feature>cxf/2.5.0</feature>
<features>camel-core/2.8.2</feature>
....
or similar to make sure the developer can get complete control over that
aspect of things. Just like with maven, transitive deps are great, but you
do need to make sure there is a way to override them.
Dan
> 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?
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
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?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
>
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Using the OBR resolver without helps a bit already, but in only helps in one
direction. If you first install the newer bundle version (e.g. Spring
3.0.6), the OBR resolver will avoid installing 3.0.5 again. But if the
first feature defines an older version (Spring 3.0.5) and you second feature
uses Spring 3.0.6, you're either getting only the old version of the bundle
or both versions (depending on the import version ranges of the other
bundles in the second feature).
For ServiceMix, I have been considering to generate an OBR repository.xml
that consists of all bundles found in all (karaf, cxf, servicemix, activemq)
features descriptors we use to fix this problem. Another option could be to
use a single OBR in-memory repository for resolving all boot features and
only then switch to the per-feature resolver implementation we are currently
using. Perhaps the latter is even a better option as it could benefit all
Karaf users without introducing any extra work for them while assembling the
container?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 3:35 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Using obr without repos already helps a lot as the featurzs deployer will
> only deploy the required bundles avoiding duplicates if possible.
>
> On Saturday, October 15, 2011, Johan Edstrom <se...@gmail.com> wrote:
> > Yup,
> >
> > I probably had spent another few days without that previous knowledge, it
> is still
> > in need of work.
> >
> > And using the OBR given the complexity I think personally is a no-go
> right
> now,
> > it isn't simple enough, nor do we have a global OBR repo.
> >
> > I did ask Tim O'Brien about a new sonatype OBR repo last week, that would
> help.
> >
> >
> > /je
> >
> > On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
I ran into this when filling the repos for an offline system.
But yep, obr solves many of the issues.
/je
On Oct 15, 2011, at 7:35 AM, Guillaume Nodet wrote:
> Using obr without repos already helps a lot as the featurzs deployer will
> only deploy the required bundles avoiding duplicates if possible.
>
> On Saturday, October 15, 2011, Johan Edstrom <se...@gmail.com> wrote:
>> Yup,
>>
>> I probably had spent another few days without that previous knowledge, it
> is still
>> in need of work.
>>
>> And using the OBR given the complexity I think personally is a no-go right
> now,
>> it isn't simple enough, nor do we have a global OBR repo.
>>
>> I did ask Tim O'Brien about a new sonatype OBR repo last week, that would
> help.
>>
>>
>> /je
>>
>> On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Using the OBR resolver without helps a bit already, but in only helps in one
direction. If you first install the newer bundle version (e.g. Spring
3.0.6), the OBR resolver will avoid installing 3.0.5 again. But if the
first feature defines an older version (Spring 3.0.5) and you second feature
uses Spring 3.0.6, you're either getting only the old version of the bundle
or both versions (depending on the import version ranges of the other
bundles in the second feature).
For ServiceMix, I have been considering to generate an OBR repository.xml
that consists of all bundles found in all (karaf, cxf, servicemix, activemq)
features descriptors we use to fix this problem. Another option could be to
use a single OBR in-memory repository for resolving all boot features and
only then switch to the per-feature resolver implementation we are currently
using. Perhaps the latter is even a better option as it could benefit all
Karaf users without introducing any extra work for them while assembling the
container?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 3:35 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Using obr without repos already helps a lot as the featurzs deployer will
> only deploy the required bundles avoiding duplicates if possible.
>
> On Saturday, October 15, 2011, Johan Edstrom <se...@gmail.com> wrote:
> > Yup,
> >
> > I probably had spent another few days without that previous knowledge, it
> is still
> > in need of work.
> >
> > And using the OBR given the complexity I think personally is a no-go
> right
> now,
> > it isn't simple enough, nor do we have a global OBR repo.
> >
> > I did ask Tim O'Brien about a new sonatype OBR repo last week, that would
> help.
> >
> >
> > /je
> >
> > On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Using the OBR resolver without helps a bit already, but in only helps in one
direction. If you first install the newer bundle version (e.g. Spring
3.0.6), the OBR resolver will avoid installing 3.0.5 again. But if the
first feature defines an older version (Spring 3.0.5) and you second feature
uses Spring 3.0.6, you're either getting only the old version of the bundle
or both versions (depending on the import version ranges of the other
bundles in the second feature).
For ServiceMix, I have been considering to generate an OBR repository.xml
that consists of all bundles found in all (karaf, cxf, servicemix, activemq)
features descriptors we use to fix this problem. Another option could be to
use a single OBR in-memory repository for resolving all boot features and
only then switch to the per-feature resolver implementation we are currently
using. Perhaps the latter is even a better option as it could benefit all
Karaf users without introducing any extra work for them while assembling the
container?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 3:35 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Using obr without repos already helps a lot as the featurzs deployer will
> only deploy the required bundles avoiding duplicates if possible.
>
> On Saturday, October 15, 2011, Johan Edstrom <se...@gmail.com> wrote:
> > Yup,
> >
> > I probably had spent another few days without that previous knowledge, it
> is still
> > in need of work.
> >
> > And using the OBR given the complexity I think personally is a no-go
> right
> now,
> > it isn't simple enough, nor do we have a global OBR repo.
> >
> > I did ask Tim O'Brien about a new sonatype OBR repo last week, that would
> help.
> >
> >
> > /je
> >
> > On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Features
Posted by Guillaume Nodet <gn...@gmail.com>.
Using obr without repos already helps a lot as the featurzs deployer will
only deploy the required bundles avoiding duplicates if possible.
On Saturday, October 15, 2011, Johan Edstrom <se...@gmail.com> wrote:
> Yup,
>
> I probably had spent another few days without that previous knowledge, it
is still
> in need of work.
>
> And using the OBR given the complexity I think personally is a no-go right
now,
> it isn't simple enough, nor do we have a global OBR repo.
>
> I did ask Tim O'Brien about a new sonatype OBR repo last week, that would
help.
>
>
> /je
>
> On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
Yup,
I probably had spent another few days without that previous knowledge, it is still
in need of work.
And using the OBR given the complexity I think personally is a no-go right now,
it isn't simple enough, nor do we have a global OBR repo.
I did ask Tim O'Brien about a new sonatype OBR repo last week, that would help.
/je
On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
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?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
>
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
Yup,
I probably had spent another few days without that previous knowledge, it is still
in need of work.
And using the OBR given the complexity I think personally is a no-go right now,
it isn't simple enough, nor do we have a global OBR repo.
I did ask Tim O'Brien about a new sonatype OBR repo last week, that would help.
/je
On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
Yup,
I probably had spent another few days without that previous knowledge, it is still
in need of work.
And using the OBR given the complexity I think personally is a no-go right now,
it isn't simple enough, nor do we have a global OBR repo.
I did ask Tim O'Brien about a new sonatype OBR repo last week, that would help.
/je
On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
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?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
>
Re: Features
Posted by Johan Edstrom <se...@gmail.com>.
Yup,
I probably had spent another few days without that previous knowledge, it is still
in need of work.
And using the OBR given the complexity I think personally is a no-go right now,
it isn't simple enough, nor do we have a global OBR repo.
I did ask Tim O'Brien about a new sonatype OBR repo last week, that would help.
/je
On Oct 15, 2011, at 12:26 AM, Daniel Kulp 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
Re: Features
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
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?
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Sat, Oct 15, 2011 at 8:26 AM, Daniel Kulp <dk...@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
>
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: Features
Posted by Daniel Kulp <dk...@apache.org>.
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