I'm in an enterprise environment as well and I can tell you two more thoughts that haven't been mentioned
1) Over here management has the same requirement of not accepting ranges for lack of testing all the possible permutations, so the solution/workaround (warning, it's pretty ugly and me personally i don't agree with it since it defeats the purpose of osgi and substitutability, but it solves the issue at hand) is to configure the maven-bundle-plugin with a different versioning policy <_consumer-policy>$(range;[====,====])</_consumer-policy> <_provider-policy>$(range;[====,====])</_provider-policy> This will make it so that ranges are always equal in its lower and upperbound, i.e. an exact match 2) In the last OSGi devcon I learnt about OSGi subsystems and deployment manifests. I haven't used them yet and there's not much documentation on them from what I can see, but it allows you to freeze dependency versions, and it seems it came from the exact same requirement you are enquiring about (someone please correct me if I'm missunderstanding something about their usecase) http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.osgi.nd.doc/ae/ra_dep_mf.html or http://www.slideshare.net/mfrancis/subsystems-for-those-occasions-where-bundles-are-just-too-small-graham-charters (Check slide # 17) You will need to check your OSGi version since I believe this is only supported in OSGi Entreprise R5 and up Let us know how it goes, I am trying to convince management to get rid of the fixed versioning policy so others' success stories might help Cheers, Alejandro Endo | Software Designer/Concepteur de logiciels From: rsteppac2 <r...@steppacher.name> To: <users@felix.apache.org>, Date: 2014-10-12 13:47 Subject: Re: Why import version range if exact version of dependency is known? Ferry, thanks for the pointer. I was aware of the concept of semantic versioning, not in the specific context of OSGi though. I read the paper on the OSGi wiki. And I still maintain what I wrote above. Example: My Maven dependency is camel-core 2.13.2. Based on the imports of the code this is converted into one or more package imports from that bundle, e.g. 'org.apache.camel;version="[2.13,3)", org.apache.camel.impl;version="[2.13,3)"', etc. I might have chosen the specific version 2.13.2 because it fixed a bug in v. 2.13.1 that affects me . Or I might have downgraded from 2.14.0 because it introduced a bug. Now, across all environments (development, test, integration, production, you name it) I have to ensure that my code always runs with that exact version of the camel-core bundle. Which is not guaranteed by the version range [2.13,3) that has been generated for me. As for my own code. I have a multi-module maven project. All or some modules will be OSGi bundles. They all have the same release cycle. Which is why I combined them in a multi-module project. So all modules are integration-tested against each other. At the same version. Even though version 3.0.0 of module A has a very high probability to work with version 3.0.1 of module B, it has never been tested that way. And therefor should never be deployed in that combination. Again, if my imports are generated as [3.0,4), then there is no guarantee that this cannot happen by accident. Might be my problem is that I don't see how to distinguish between the API and its provider. The bundle "camel-core" is both, is it not? The same is true for almost all 3rd party libraries I normally work with. Very few separate the API from the provider in separate bundles. Of course with my own code I could go the extra mile maintain separate modules for the API and its provider. Thanks for your help! Ralf -- View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010137.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
