Oooo threadjack! To get things back on point, I make the following suggestions. Don't take the tone of the suggestions to strongly, this is just my opinion.
I agree with Guillaume that we can't have too many dependencies on other products. If this were an J2EE container, we would include specific items implementing the J2EE functionality as defined by the spec, and a few "nice to haves". Then, anyone who wanted to add functionalilty would need to do so by themselves. If we look at Karaf as a container that implements all the bells and whistles of the current OSGi specification, we will have a nice line of demarcation. So, when deciding on a new piece of functionality: 1) License? (ASL or not a candidate) 2) does it implement something defined in the OSGi spec (services, provisioning, etc), 3) Is its intent to be specific to Karaf (Cellar yes, Aries no), and 3) Are there other products that can implement that functionality using Karaf already? If a piece of functionality (or another product) gets a no (or a weak maybe) in one or more of the above categories, they would be a great candidate for use with Karaf, but not as part of the Karaf distribution. If, like Cellar, they are specific to Karaf and add functionality we would like users to have, then they would be a great candidate to be a sub-project. Any sub-project or other product that wants to work with Karaf would be responsible for making sure it runs in vanilla Karaf (creating a features.xml file, deploying, working, etc) and doing regular releases (defined as a full product distribution deliverables complete with their own .zip or .tar and a features.xml file). The last caveat I'd like to add is that if a product is optional, or external to vanilla Karaf, it should have its own distribution. The biggest question this creates is: what to we do with things that are technically optional, but so tightly itertwined with Karaf that they won't work outside of Karaf? For example, how do we treat the webconsole? Well, either it is part of the vanilla Karaf distribution, or it is not. If it is not, we should create a seperate deliverable for it. That way, there's no confusion about how to get it (especially for environments that are not connected to the big-bad internet.) gsilverman wrote: > > You camel/karaf officiondos can yap all you want to each other. All I want > to do is run camel-cxf in karaf, and I can't. I even tried camel-cxf > 2.8-SNAPSHOT with karaf 2.2.1. The instructions on the Apache Camel:CXF > Example OSGi page, if anyone can actually follow them, don't work (is > there a cxf feature to install?). > > I even tried replacing the etc/jre.properties in Karaf with the one in > ServiceMix 4.3, as someone suggested, and that didn't work. > > If there's a secret to get this to run, I and I'm sure a lot of others > would like to hear about it. > ----- Mike Van (aka karafman) Karaf Team (Contributor) -- View this message in context: http://karaf.922171.n3.nabble.com/Thoughts-about-Karaf-profiles-releases-growing-number-of-dependencies-Re-AW-AW-Problem-when-starting-tp2419227p2954108.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
