Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] EMF Plug-in Versioning and Reexported Dependencies

> Any input would be greatly appreciated.

Ok, you asked for it ... so ....
but how about option 3? Remove the re-exports if they are not part of _your_ API, but
provide a compatibility layer for binary compatibility.

I've seen this re-export practice (mis)used quite a bit in some rather large plugin stacks, basically causing
complicated "hidden" dependancies. (not necessarily directly related to your practice, just the practice in general).

And, I think issues caused from these unnecessary re-exports will only get worse as interdependencies get more complicated,
and especially as people start to use more Import-Package instead of Bundle-Require -- they may _really_
not need the other stuff you re-export if they have some very limited dependancy.

We in WTP would be willing to adjust to this change, if/when we move to your major
incremented version (and we likely would, as long as there's no (other) effects to our adopters).

I'd love to hear other's opinions too, and, of course, you'd want to check with your
other major product adopters! :)  

The compatibility option might get complicated, but you could probably almost automate it.
The "compatibility layer" option, would have new non-re-exported versions having new names, and the
plugins with old names import the new, and re-export them and re-export what ever they did before,
that would, provide a binary compatible non-breaking changes ... and those that adopt to the
new versions could completely omit the compatibility layer in their product installs,
when they were ready.

If you go with the non-breaking compatibility layer. creating new plugins
with different names, you could also correct your naming scheme, so it the new stuff would
be "org.eclipse.modeling.emf"? :)

Oh, and by the way, if you go with the compatibility layer, I'd just go with the easiest version number scheme possible.
I don't think strict versioning rules would be required for basically a temporary solution.

Dave Steinberg <davidms@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/18/2006 11:19 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

[cross-project-issues-dev] EMF Plug-in Versioning and Reexported        Dependencies

Hi all,

EMF has a plug-in versioning problem, and I'm looking for some input (especially from those who depend on us) on how we should go about solving it.

We're striving to correctly follow the plug-in versioning guidelines (, which contains this statement:

"Plug-ins re-exporting other plug-ins tie themselves to the re-exported plug-ins, since they are making the re-exported plug-ins part of their API. Therefore, the version of such plug-ins must indicate the most significant type of change between all the plug-ins they re-export and the changes made locally."

EMF re-exports plug-ins extensively.  This was a decision made many years ago, when we really didn't understand what its consequences would be.  As a result, depending on just about any plug-in in EMF automatically pulls in the APIs from just about every other plug-in that it depends on.  Today, it seems the accepted wisdom is, "don't do that!", but unfortunately we've already done it.

The first change I made in our current development stream was to add a method to an API in org.eclipse.emf.common.  Endeavoring to follow the rule, I mapped out the tree of EMF plug-ins that reexport that plug-in.  This is just like the tree you'd see when you click "Show Callers" in the Plug-in Dependencies view, except it only includes dependencies that re-export.  Rather than waste 234 lines to reproduce it in all its glory, I'll just say that it includes almost every last plug-in in EMF.  Trying to propagate version changes through these huge trees of re-exporting dependencies in EMF would be difficult to manage and prone to introducing error.

Moreover, I believe the results would differ only marginally from treating all of EMF as a single monolithic unit, and simply incrementing all of our plug-ins' versions in step each cycle.  And that was precisely the practice that these versioning guidelines were intended to put an end to.

So just following the rules doesn't seem to be a reasonable solution.

After giving it some thought, the EMF team was able to come up with two other possibilities:

1. Remove our re-exports

We could improve the situation simply by removing all the unnecessary re-exports in our plug-ins.  We would have to change our own plug-ins to explicitly require all of their dependencies, which of course wouldn't be a problem. The problem is that this would be a breaking change, probably for almost all of our clients.  The fix would be trivial: just use the excellent PDE tools to explicitly add missing dependencies.  But is that something that people would find overly disruptive?

This should probably be considered a change of API, so we would have to increment the major version numbers of all affected plug-ins.  But, we're planning such a version change anyway, when we build our plug-ins to target Java 5.  So, this would seem an ideal opportunity to make this kind of change, leaving us in a good position to do versioning correctly in the future.  This is our preference.

2. Ignore the rule and treat re-exported plug-ins independently

We could pretend that we never started re-exporting plug-ins in the first place, and just increment plug-in versions based only on their own changes.  This would save those who aren't concerned interested in strict per-plug-in versioning from facing newly broken dependencies, and would still communicate something useful, but would not respect the expectations of those who are relying on strict plug-in versioning.

One idea we came up with was a new feature for Equinox: if a new directive could be recognized on Require-Bundle to mean "ignore any of this dependency's re-exports", then we could provide proper plug-in versioning (by not considering re-exported plug-ins) for those who choose to "opt in" by using this directive when they depend on our plug-ins.  Alternatively, it could just be a development-time feature in the Plug-in Manifest Editor.  By enabling it, re-exported plug-ins would be ignored, and people could use the tool to add all their dependencies as explicitly required.

This seems like something that could be generally applicable in situations like ours, where re-exports have been used in the past, resulting in a non-modular set of plug-ins.  However, if this isn't a widely shared problem, or if this idea is viewed as just adding more complexity, then that would seem to support option 1 as the best way to go.

Any input would be greatly appreciated.



Dave Steinberg
Rational Software - IBM Toronto Lab
cross-project-issues-dev mailing list

Back to the top