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 <gno...@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 <seij...@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 > >> dk...@apache.org > >> http://dankulp.com/blog > >> Talend - http://www.talend.com > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
