camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <seij...@gmail.com>
Subject Re: Features
Date Sat, 15 Oct 2011 18:28:12 GMT
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 <seijoed@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


Mime
View raw message