I guess this is a sad consequence of poor cohesion in the original package design.
As Richard said, one choice would be to properly refactor into new package names and have the orginal package delegate to the new packages for existing code that does not/cannot be itself refactored to use the new package names. Given that will likely not happen, I think you will need to keep the version numbers of the package in sync so that any change to any portion of the split will uplevel the package version in every bundle. The reasoning is that logically there is only a single package that is physically split across multiple bundles. A bundle that gets the package from the aggregator bundle will see the complete package and any change in any split will be visible. A bundle that gets only a split of the package from one of the other bundles may see a version change even though nothing actually changed in the split, but that should be OK assuming the bundle does not use an overly restrictive version range on the import. Also, I think you should consider a different attribute design for the split org.eclipse.core.runtime (original bundle) Export-Package: org.eclipse.core.runtime; version=3.2; common=split; registry=split Require-Bundle: org.eclipse.equinox.common, org.eclipse.equinox.registry org.eclipse.equinox.common Export-Package: org.eclipse.core.runtime; version=3.2; common=split, mandatory:=common org.eclipse.equinox.registry Export-Package: org.eclipse.core.runtime; version=3.2; registry=split, mandatory:=registry This will allow the consuming bundle to be wired to either the aggregator or the split bundle and even provides the flexibilty to combine the splits in any way in the future should your needs change. (note the attribute value does not have to be "split", I just chose it for the example). BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788 Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2006-03-31 08:58 AM Please respond to OSGi Developer Mail List <osgi-dev@bundles.osgi.org> To osgi-dev@bundles.osgi.org cc Subject [osgi-dev] split package version numbers In a thread on equinox-dev the following was said. Peter Kriens wrote on 03/31/2006 03:17:07 AM: > 2. If you have sloppy exported packages, you probably also have sloppy > virtual bundles. All bets are off. A package with the same version, > and same name MUST contain substitutable content. If you do not > accept this condition, then please skip :-) the remainder of this message; > package atomicity is one of the premises of OSGi modularity. This makes total sense. Tom and I were just the other day going over a case where we have a three-way split in a package because of some refactoring. We used to have org.eclipse.core.runtime 3.2.0 in one bundle but parts of that package got moved out into two other bundles (i.e., three-way split). For backwards compatibility we are using mandatory attributes as follows org.eclipse.core.runtime (original bundle) Export-Package: org.eclipse.core.runtime Require-Bundle: org.eclipse.equinox.common, org.eclipse.equinox.registry org.eclipse.equinox.common Export-Package: org.eclipse.core.runtime; split=common, mandatory:=split org.eclipse.equinox.registry Export-Package: org.eclipse.core.runtime; split=registry, mandatory:=split So the core.runtime bundle acts as an aggregator for the split package. Anyone who simply imports org.eclipse.core.runtime will get it from the core.runtime bundle. People wanting a specific package split can spec the "split" attribute. Ok, so now comes the question: how do we evolve the version numbers of the different splits. In effect what we have done is broken the org.eclipse.core.runtime package up into two sub packages (common and registry) which can be evolved and consumed independently. The one in the core.runtime bundle is then an aggregation of the others. It seems like the subpackages can evolve their version numbers at a rate appropriate to their change and the aggregator should then evolve its version number based on the change in the subpackages and changes to itself. So you could end up with different version numbers on all three package exports. On the surface this seems confusing but it actualy correctly captures what is happening and allows people to spec their dependencies accordingly. Thoughts? Jeff _______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
