On 22 December 2014 at 21:57, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Am Mon, 22 Dec 2014 21:43:01 +0000 > schrieb sebb <seb...@gmail.com>: > >> > a) follow the math lead and make it org.apache.commons.vfs2 (asuming >> > this does not break anything from 2.0 to 2.1) >> >> If the OSGi bundle name relates to the Java package name or the Maven >> coordinates then this might break things. > > Well, 2.0 would be broken, I wonder if it should be fixed with 2.1 > >> What is the OSGi name actually used for? > > The Bundle-SymbolicName is the symbolic name for a JAR. It is together > with the version uniquely identifying a bundle in OSGi.
OK, so provided that VFS does not re-use version numbers then AFAICT a fixed name should be OK from that particular point of view. > It is mostly used for other jars to depend on it with "Require-Bundle". > However require-bundle is seldomly used (normally you import packages > instead) > > The bundle plugin uses by default the group.artifactid, but that does > not mean it is required to add major versions. I guess it would however > not harm to have a different ID if the packages change, as the bundle > would not be useable for an older consumer anyway. > > I guess it is mostly a question on tooling, if you want to see that > there is a new (major) version of a bundle available (which you would > only see if you keep the same symbolic name). But if we always use the same symbolic name, it may look as though an app that was built using VFS2.0 will just be able to use VFS19.2 without any adjustments. However, that may not be the case. In order to only identify jars that are upwards compatible, the OSGi name needs to change whenever this changes. So I can see why the default is group.artifactId. Looks like any other choice would have disadvantages. > Gruss > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
