We have faced the same issue in Camel before.
As you know we don't want Camel feature have the dependency on the specific 
version of Karaf.
We don't specify the version of karaf feature which we want to use, and leave 
it to Karaf container to pickup.
In this way we just leverage all the features or bundle karaf can provide for 
us.  

I think we can introduce some assemble mechanism like maven pom to let the 
people to specify the version of feature. 
BTW, we also need to drop a good line between the karaf core and other sub 
features to decouple the dependencies.
The the sub features can be used with different version of karaf core.

Any thoughts? 

-- 
Willem Jiang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) 
(English)
          http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang



On Thursday, October 18, 2012 at 7:03 PM, Achim Nierbeck wrote:

> Hi,
> 
> I really like this idea of separate feature files.
> And I think we really should at least give it a try.
> I fully understand the "fears" of Ioannis, Guillaume and Freeman
> cause as I tried to seperate the pax-web features from Karaf
> I just stumbled over a couple of constraint I didn't see right
> from the beginning.
> Like Camel depends on the http feature, this feature also
> provides Karaf specific commands and so forth.
> I think it can be done and I'll try to work on this as soon as possible,
> still I think we will find such shortcomings with other features, too.
> 
> But if we stick to the way it is right now, we do get the feedback
> it's not modular enough :)
> 
> regards, Achim
> 
> 
> 2012/10/18 Christian Schneider <ch...@die-schneider.net 
> (mailto:ch...@die-schneider.net)>:
> > I think the goal to have separate feature files that are independent of the
> > karaf version is good.
> > Like Ioannis I am also unsure if it can be done right now. At least the
> > recent karaf versions would not have allowed that.
> > So before really starting this we should make sure we can deliver these
> > independent feature files.
> > 
> > Christian
> > 
> > 
> > On 10/18/2012 09:52 AM, Ioannis Canellos wrote:
> > > 
> > > The idea seems good at first glance, but there are things that we need
> > > consider.
> > > 
> > > In many cases a feature descriptor is not portable between major Karaf
> > > versions, and it also happens that it breaks between minor versions.
> > > 
> > > Even from Karaf 2.2.x to Karaf 2.3.x I've seen third party features break.
> > > So it may seem that most features could decoupled from the underlying
> > > version of Karaf, but practically this is not always the case.
> > > 
> > > An example: In the spring feature case, we also have the spring deployer.
> > > Where will the source of spring deployer will be hosted and which are
> > > going
> > > to be the versions of fileinstall and karaf that the deployer will be
> > > built
> > > against?
> > 
> 
> 
> 
> 
> 
> -- 
> 
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>



Reply via email to