I work on an Eclipse plugin called CFEclipse.
CFEclipse has a built-in unit testing plugin, but it's old and pales in comparison to another available unit testing plugin called MXUnit.
So I wanted to replace the built-in plugin with the MXUnit plugin.
I needed to bundle MXUnit with CFEclipse, and still allow people to update from MXUnit if a newer version came out before I could bundle it with CFEclipse, however.
I thought that adding a "discovery" child to the "url" node (pointing at the MXUnit update site) as well as adding an "includes" node to the feature.xml would get me there:
<update label="CFEclipse Update Site" url="http://www.cfeclipse.org/update"/>
<discovery label="CFEclipse discovery site" url="http://cfeclipse.org/update"/>
<discovery label="MXUnit discovery site" url="http://mxunit.org/update"/>
I figured thusly because that's what I could find searching the web using terms like: "including 3rd party plugins" or "using two update sites" and whatnot.
The only problem was, this seemed to lock anyone who installed the bundled CFEclipse + MXUnit into whatever version of MXUnit we bundled (specifying 0.0.0.0 as a version number didn't help).
I figured if I could specify a revision range for MXUnit, that should "unlock" updates from the main MXUnit update site.
Unfortunately, looking through the docs, it appeared you could specify revision ranges for dependencies, but not for plugins you include in the feature.xml.
Back to the search-board!
The magic search string was: "feature.xml includes version ranges"
Which led me to this:
Which had the following info:
There are two approaches, the first is to change the feature to require the plug-in instead of include it. This gets you the old update style ranges of equivalent[1.2.3, 1.3.0), compatible[1.2.3, 2.0.0), or greaterOrEqual. However, PDE/Build currently only builds included plug-ins, not required ones. So you would need to build the bundles separately and then have them (and their metadata) available to the product build.
The other and perhaps simpler option is for the feature to have a p2.inf beside the feature.xml. The p2.inf can add requirements to the feature, and they replace the generated requirements that came from included plug-ins if the name and namespace are the same.
feature: include org.eclipse.foo 0.0.0 p2.inf: requires.1.namespace = org.eclipse.equinox.p2.iu requires.1.name = org.eclipse.foo requires.1.range = [1.0.0, 2.0.0)
If you are changing the requirement ranges for include features, remember that the name for a feature's IU has ".feature.group" appended to it.
Ah ha! I opted for the p2.inf approach, although I think the former might be better if you have to support pre Eclipse 3.3 plugins. Option two was definitely the easier of the two, too. :)
After adding the p2.inf, things worked like I'd wanted, where the update to MXUnit can come from either the main MXUnit update site or the CFEclipse update site.
This decoupling allows the end users to choose when and where to get their MXUnit updates, vs. forcing them into using whichever version CFEclipse ships with.
Ironic that it took a few hours of dicking around with stuff and searching to find a 3 line solution, but that's Eclipse development. Things that are simple in retrospect can be rather difficult to unearth initially.
I think this is a result of the size of the Eclipse codebase, and the constantly changing nature of it- neither of which would I trade in exchange for easier docs.
If Eclipse was closed source, I'd sing a different tune.
And targeting a different platform.