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
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