Following on from the previous post, I've put together something that might make life a little easier when dealing with the internals of plug-ins. There's already a Plug-ins view (see screenshot, right) which will show you what plugins are installed in your local Eclipse install, and you'll be able to import them into your workspace as binary, source or binary+linked content. Great if you want to find out about something, but not so good if you want to submit a patch, because you have to go into the repo (first, finding which of the 6 or 8 repositories that it is) and then try and find the plugin.
Enter stage right, the download-a-plugin-from-repository action1. This puts up a handy little icon () in your toolbar2, and when you select one (or more) plug-ins from the plug-ins view and click this button, it will try3 and download them from the Eclipse repository into your workspace. If all goes to plan, you'll have the Head version checked out to your workspace.
There are, of course, some caveats. Firstly, it only works with CVS at the moment; SVN will just have to wait. Secondly, it's not all-knowing; it has a stab at where the plug-in might live, but it might either guess wrong or not even know where to look. Thirdly, it's likely to be one of those everlasting betas that you hear about, and that would be kind. Usual disclaimer, use at your own risk, blah blah blah.
If you're interested, the way that it works is comparing the plug-in name with a known mapping of name-to-location. For example, here's how it knows where to download the ECF code from:
<repository prefix="org.eclipse.ecf" location=":pserver:email@example.com:/cvsroot/technology,org.eclipse.ecf/plugins/"/>
Anything that begins with
org.eclipse.ecf will use this location. If there's a more specific pattern (e.g.
org.eclipse.ecf.example comes from anywhere else) then it'll use that in preference. I've put a bunch of them in the plug-in, but it's just an extension point so you can contribute your own if you want.
You can also override it with the decidedly non-standard
X-Eclipse-RepositoryLocation: :pserver:firstname.lastname@example.org:/cvsroot/eclipse manifest entry in your bundle if you want. This takes precedence over any of the repository bits, and might be a bunch easier to set up. I wouldn't worry about trying to support it now, though, since this may never become standardised.
Note that it expects the name of the plug-in to exist in the repository. What it actually will look for in the example case above is:
:pserver:email@example.com:/cvsroot/technology/org.eclipse.ecf/plugins/org.eclipse.ecf.example and check it out to a project of the same name. If that doesn't exist, it will fall over (and probably not import anything else you might have selected). In general, if your CVS repository contains the plug-ins directly by name, you don't even need to put anything after the comma: for
org.eclipse.equinox the repository would be
Let me know what you think of it by commenting here; or reporting to the bug 195729 report. (Preferably use the bug report for reporting problems with it). You can download the plug-in from the bug attachment; it's a bundle you can just drop into your plugins folder, but also contains the sources for you to play around with.
- I'm not very good with names
- Yeah, the toolbar is an ugly solution. However, the Plug-ins view doesn't allow anyone to insert an action into the pop-up menu, so this was a good choice for those wanting to play around with it; if enough people like it, it might make it into the next Eclipse
- Best bet is to try one at a time; it gives sensible messages when it doesn't know about a repository (in which case, you can add one as above) but it's known to fail silently when it thinks it knows where a plug-in should live but it doesn't live there