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 [email protected] http://bundles.osgi.org/mailman/listinfo/osgi-dev
