You basically have 3 ways to express a dependency on a feature (discarding the versioning stuff)
<feature dependency="true">xxx</feature> <feature>xxx</feature> <feature prerequisite="true">xxx</feature> The first one means the resolver may include the given feature to solve a constraint, but this is not a requirement. For example, the constraint may be solved by a different feature which is already installed. It's similar to <bundle dependency="true">. An example would be if you want to allow different providers for a given service. It's not used a lot yet in 4.0.x but it will be much more leveraged in 4.1.x. A real example is pax-web 6.0, which defines a pax-http feature with a reference to pax-http-jetty feature with a dependency="true" flag : this allow the user to install either "pax-http", in which case, the jetty provider will also be installed, or "pax-http" + "pax-http-tomcat", in which case, the "pax-http-jetty" feature won't be installed because the provider is already provided by the "pax-http-tomcat" feature. In 4.1.x, this will be the case when multiple providers can be chosen : pax-web, pax-cdi, transaction manager, jpa provider, etc.. The second form is the most basic way : the listed feature will be installed at the same time. Keep in mind that with karaf 4, features are not installed one at a time anymore. The feature service use the OSGi resolver and the set of features to install (or other generic requirements) and computes the list of bundles to install. With this way, the two features will be installed at the same time. The last form (prerequisite="true") is provided in order to actually have the two features installed one at a time. This is usually not needed. The only real time it is needed is when the feature service need the dependency in order to be able to resolve the main feature. For example is the main feature use the "wrap" url handler for a bundle, the resolver needs the url handler to be available to download the bundles so that the osgi resolver can be run. This is really the only real use case I have in mind for the prerequisite="true" flag. The effect of this flag is that the feature service will first install any prerequisites, start the feature, and then do a second pass. 2016-09-13 17:15 GMT+02:00 oski_bear <dariusham...@hotmail.com>: > Hi Guillame, > > Firstly, thanks for looking into this. In regard to the "overuse of the > prerequisite flag", keep in mind that the project I checked in is > completely > artificial. Before checking in the project, I removed many references to > bundles that are not in the public maven central repository from the > feature > definitions so that you could reproduce the issue. > > However, it is possible that I am still overusing the prerequisite flag, > and > in that case can you please explain to me what the objective criteria are > for using the prerequisite flag? > > I assumed that if a feature has bundles which depend on bundles provided by > another feature then I should use the prerequisite flag. For example, camel > needs jline and jline is provided by the shell feature so why shouldn't > camel mention "shell" as a prerequisite? > > Alternatively, can you show exactly where in the project there are > redundant > uses of the prerequisite flag and explain why it is redundant so that I > don't make the same mistake again? > > > > > -- > View this message in context: http://karaf.922171.n3.nabble. > com/Features-Core-bundle-stuck-in-Resolved-state-tp4047964p4047998.html > Sent from the Karaf - User mailing list archive at Nabble.com. > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
