>> *I think this is why people have pretty much universally adopted FQN for bundle symbolic names, and I think the same reasoning applies here.*
Yes, you are right on this. However, there are quite a few differences between feature names and symbolic names that I think we should take into consideration: a) Symbolic names have to be unique. b) You don't use symbolic names to provision your bundles (install,uninstall, start & stop). For that purpose you use the bundle id. I don't disagree that FQN is the perfect solution in order to distinguish features. I am just saying that its not very friendly to the user. *>> We're planning to release them for karaf 3, IIUC you want to name them things like aries-jndi version 3.0.0. Next week aries creates a similar feature and calls it aries-jndi version 3.0.0, and we pack it up in a feature repository we distribute. How do I know which feature I'm getting?* I must say this concern is valid and we do need to provide a clean solution for this. Here's what I am thinking: This case doesn't apply to all features, but to just some of the features. I feel that applying a naming policy to ALL features just to be able to resolve possible ambiguities that apply to some of the features is not the way to go. Especially, when the naming policy generates clutter and is somehow more difficult to use. So, I would like to propose that we use the repository id in order to resolve these ambiguities as we already do with versions. For example: If we have the same feature for multiple versions we can do something like: features:install <name>/version. We could do something like: features:install <repo-id>/<name> or features:install <repo-id>/<name> /<version>. What do you think? -- *Ioannis Canellos* * FuseSource <http://fusesource.com> ** Blog: http://iocanel.blogspot.com ** Apache Karaf <http://karaf.apache.org/> Committer & PMC Apache ServiceMix <http://servicemix.apache.org/> Committer Apache Gora <http://incubator.apache.org/gora/> Committer *
