Use Your Metadata, Vol. 2 [Update]

Wednesday I went off on a bit of a G'n'R-fueled rant about metadata, documentation, and the shotgun blues. Today, I'd like to focus on something more positive.

As Pascal blogged the other day, the new p2 is almost done and is ready for tire-kicking. Some new features I personally like include:

1. a new p2.director app / task, which includes support for installing multiple IUs (feature.groups) in the same step and finally has commandline help
2. a new p2.repo2runnable ant task, used to convert an update site zip to the old-school unpacked "runnable" features/plugins format so that one day we will be able to throw away all those extra zips.
   
   UPDATE, 2009-06-02: repo2runnable now works as a commandline application too, thanks to Andrew's fix. Wiki updated.
3. Composite Repo, Mirroring and Slicing Tasks - haven't tried these yet, but they look like they'll be very handy for one day replacing the hack that is buildUpdateSite.sh for our Modeling Project composite repos with something more robust and easily maintainable.

I'm also impressed that there is new, current documentation regarding the above tasks, as well on the new Publisher which replaces the Metadata Generator.

Will this release be p2's salvation?

click to zoom

Well, I'm split on the new default behaviour in the update UI, such that when you add a new update site p2 won't by default search ALL your other listed sites. This is a great performance gain if you're installing a new self-contained feature, but a pain if you're installing something like VE which depends on EMF and GEF, and you don't already have those deps installed. Simple workaround is to just pick the "all sites" entry in the dropdown.

I'm also waiting to see if there will be something better done about recovery from slow/incomplete mirrors.

But other than these minor concerns, I'd say YES. With lots more commandline and ant toys available, p2 is certainly maturing. And with more people adopting its use and spinning p2 repo zips, more testing is being done, and more use cases are being covered.

So... get in the ring, and go a few rounds with p2. It's worth the battle. :)

Use Your Metadata, Vol. 1

It's been a bad week for update sites and Galileo contribution from Modeling... and I confess I'm partly to blame. That and the fact that despite documenting processes, workarounds, tips, tricks, and advice... no one Reads The Fine Mediawiki (Category:Releng or Modeling Project Releng).

Highlights:

1. The mysterious appearance of a new version of org.eclipse.osgi_*.jar in releng.basebuilder's R35_M5 tag, which caused an ant <copy/> used to rename a file to fail because copy can't merge two jars into one file. Still no idea why an old basebuilder tag would magically grow a new jars, but I've worked around the now-faulty assumption w/ smarter Ant code.
2. A change to the way our sites are created, in an attempt to workaround what I believe (but can't yet prove) is a flaw in the way content.xml is produced - namely, if the xml file is > 21M, it gets truncated or corrupted. We used to cache 2 or 3 releases of a given project (eg., M5 and M6) on the same site, in order to give people a way to "back up" to the previous release; now, you only get the latest (bug 271486). I confess I screwed up here and instead of replacing a folder with new contents, I was copying INTO that folder - `cp -r one two` resulted in folder one/two/ instead of two/. I fixed that by changing to a move instead of a copy, but a downstream process failed because of the assumption that both one/ and two/ would exist. The lessons here are: a) shotgun debugging sucks, and b) don't change the way stuff is created after M7.
3. People publishing two updates to a site at the same time, resulting in the appearance of two </site> tags in a site.xml file, causing p2 metadata generation to be incomplete or fail entirely; unfortunately, no error is logged when this happens so it's rather difficult to decipher the tea leaves. This may be the real source of the metadata corruption, if not the "file is too big" issue above.
4. Observations about obsolete jars corrupting metadata, but no one taking it upon themselves to clean up the site or do some troubleshooting
5. People inconsistently naming their milestones (it's 2.0.0M7, not just M7!) and corrupting our Release Notes database. This one amazes me the most since it takes seconds to see what was done last time (check any of the following: RSS feeds, release notes, downloads pages, update sites) and follow suit. And, of course, the conventions are documented, along with the rationale (consistent patterns == simpler code).

Or, to put it another way...

Sick of this life
Not that you'd care
I'm not the only one with
whom these feelings I share

Nobody understands
Quite why we're here
We're searchin' for answers
That never appear

But maybe if I looked real hard I'd
I'd see your tryin' too
To understand this life,
That we're all goin' through

Sometimes I feel like I'm beatin' a dead horse
And I don't know why you'd be bringin' me down
I'd like to think that your love's
Worth a tad more
It may sound funny but you'd think by now
I'd be smilin'
I guess some things never change
Never change

So, please, can we stop opening bugs (277172, 277105, 277034, 276928, 276641) and just use the tools and docs already available?

Download Stats & Missing Data

According to Google Analytics' new "snot graph" tool, the top three downloads in Modeling these days are, in order: EMF, UML2, UML2 Tools.

OK, no big surprise there. But what's really surprising is that people are still downloading zips. Isn't it easier to get your bits via Update? Isn't that why we provide you, the community, with over 20 Modeling update sites (three per project), so you can pick and choose what features to install, rather than downloading & unpacking zips? (Not to mention the countless other sites provided by DSDP, WTP, BIRT, DLTK, DTP, Mylyn, PDT, Equinox, Eclipse, GEF...)

Hell, with the advent of Eclipse 3.4, you can now even update the platform itself, so the Eclipse experience need only be one zip + a ton of multi-threaded updates. Say what you will about p2 (and I've said my share) but isn't it faster and easier than having to download zips?

I can understand being stuck on a platform version from a while ago, but with Eclipse 3.5 only 4 months away (yikes!), and e4 due next year, should anyone still be using Eclipse 3.0 or 3.1 and EMF 2.0 or 2.1? You're missing out on over three years of new development!

What's even more bizarre to me is that when maintenance releases are available, people still download the point-zero releases. Are we wasting our time doing maintenance? Should we be focusing on the next release instead? (In related news, Ganymede SR2 is just around the corner. Is everyone ready for what will be the final chapter for the Eclipse 3.4 stack?)

Of course the one glaring hole in all this data are the numbers around how many update jars are downloaded. If you'd like to see this resolved, have a look at bugs 239668 and 187968 and vote accordingly. It's really depressing to think that since September 15 we've only had 150,000 downloads (100,000 unique) when in 2006 we broke 1,000,000 downloads for 2006 on December 1 of that year, averaging just under 100,000 downloads a month.

Either the popularity of EMF - and of Modeling - has waned by two thirds, or we need a better way to capture stats.

HOWTO: Use the p2 Update UI to control where you install

A few months ago, I wrote about using the p2 director to control where you install plugins & features.

Here's the other approach I mentioned in that article -- using the p2 Update UI and a little filesystem trickery.

1. Use the p2 Update UI (Help > Software Updates... > Available Software) to install what you want. When prompted to restart, click No -- DO NOT RESTART OR APPLY CHANGES.
2. Open a console window and run ./moveInstall.sh foo 10 to move all plugins and features created in the last 10 minutes from ./plugins and ./features into ~/eclipse/eclipse-plugins-foo, then link them from ./dropins/foo.link.

   Note that the name, foo, is arbitrary -- it can represent the specific feature set you just installed (eg., "jet" for JET plus dependencies) or it could be something generic like "team", where I've got plugins for Mylyn, Tasktop, Subclipse, CVS, JIRA, and Bugzilla. You can also add/replace plugins & features in an existing folder by running the script again.

3. Use the p2 Update UI (Help > Software Updates... > Revert Configuration) to revert the changes you just installed by selecting the timestamp of the configuration from BEFORE you installed the plugins & features in step 1.

   Since you moved the files when Eclipse wasn't looking, it simply removes the p2 metadata, but can't delete the plugins and features.

4. When prompted, restart Eclipse. On restart, the new plugins & features will be loaded.

Because the new plugins & features are not in the Eclipse root, you can now use those plugins with multiple versions of Eclipse -- just copy the foo.link file into another Eclipse's dropins/ folder.

This is perfect for testing milestone builds without having to reinstall everything each time.

Of course it's so easy to do this in shell script I have to wonder why p2 can't do it under the covers so we can get back the old functionality from Eclipse 3.3...

Request For Comment: The End Of SDO?

Four months ago, I started a discussion about simplifying the EMF download experience. Consensus appears to be that we should keep the EMF-SDO-XSD "All-in-one" SDK zip, perhaps more.

Now, a new proposal is in the works: removing SDO from the EMF build, and from this year's coordinated release, Galileo. The source would still be in CVS, but we'd stop providing SDO binaries. This would also mean the much-loved^* EMF-SDO-XSD "All-in-one" SDK zip would be renamed to EMF-XSD "All-in-one" SDK, but would otherwise continue as is.

For more on this topic see:

EMF 2.5 - Simplified Downloads (bug 240223)
Remove SDO from Galileo (bug 251402)
Consider improvements to the termination process (bug 249408)

To voice your opinion, please post your feedback in any or all of the three bugs linked above.

Thanks!

Request For Comment: Will Anyone Miss All Those EMF Zips?

With the advent of p2 and the smaller EMF features introduced in EMF 2.3, the EMF team is evaluating if the All-In-One, Runtime (3), Sourcedoc (3) & Examples Zips are still meaningful and useful to consuming teams, projects, and products. We'd like to reduce those 8 zips down to a single archived update site zip.

For more on this topic see:

EMF 2.5 - Simplified Downloads

To voice your opinion (be it 'I need that/those zip(s)!' or 'I'm good with using Update'), please post your feedback in bug 240223.

Thanks!

Visual Editor for Eclipse 3.4 Ganymede

There have been a number of questions in eclipse.newcomer lately about the availability of a visual editor for Eclipse 3.4 Ganymede.

So, I thought I'd see if VE 1.3 can be installed into Ganymede using p2 -- and in fact it's pretty easy to do.

As noted in VE Installation Guide, you can use the "Eclipse IDE for Java EE Developers"... but because I usually run with the Eclipse SDK, rather than an EPP bundle, I wanted to know what the minimum requirements are for VE, so I unpacked VE into Eclipse's new dropins/ folder, and started Eclipse with the OSGi console active, using this script:

#!/bin/bash
workspace=/tmp/workspace-clean-34
pushd ~/eclipse/34clean >/dev/null
if [[ $# -eq 0 ]]; then
        rm -fr eclipse $workspace emf-unpacked
        eclipse=eclipse-SDK-3.4-linux-gtk.tar.gz
        echo "Unpack $eclipse...";
        tar xzf $eclipse
        ve=org.eclipse.visualeditor-1.3.0.200709121813
        echo "Unpack ${ve}.zip into dropins"
        unzip -q ${ve}.zip -d eclipse/dropins/ve
        mv eclipse/dropins/ve/$ve eclipse/dropins/ve/eclipse
fi

vm=/opt/sun-java2-5.0/bin/java
echo "Using vm=$vm and workspace=$workspace"; 
./eclipse/eclipse -vm $vm -data $workspace \
  -consolelog -clean -debug -console -noexit -vmargs \
  -Xms128M -Xmx256M -XX:PermSize=128M -XX:MaxPermSize=256M
popd >/dev/null

What I found was that the console listed all the missing dependencies for the VE feature, making it easy to find the features I needed to install to fully enable VE. I fired up the Help > Software Updates and installed the following from the Ganymede Update Site:

On restart, I had a working visual editor:

p2'd

With Ganymede M7 just around the corner, and Eclipse 3.4M7 in the can, it's time for everyone to start playing w/ p2 again. It's come a *LONG* way from where it was in M6, thanks to the tireless efforts of the Equinox team. If you tried it then and got scared, please give it another look -- it's a much more user-friendly animal today. The promise presented at EclipseCON is coming true, despite some people's misguided attempts at humour last time around.

If you haven't tried converting an existing update site into a p2-enabled one, you should. I was very pleasantly surprised how easy it was.

And now, some Beatles for your Friday afternoon entertainment...

p2'd: it's not so bad
Took a sad song, and made it better
Remember to test drive it today
So you can help to make it better

p2'd: don't be afraid
You're now used to use Update Manager
The minute p2 gets under your skin
Then you begin to see it's better

And any time you feel a pain's p2'd, refrain
Don't carry the world upon your shoulders
Well don't you know that it's a nug who don't file bugs
Be they grit or Sisyphean boulders

p2'd: won't let you down
You'll have found the new Install Manager
Generate extra jars for your site
And you'll see that it's made much better

So try it out, yes, it's time for p2 to begin
Stop waiting for code freeze to download it
And don't you know that it's for you, p2'd
You'll do, the details you need are in the wiki

p2'd: works really well
Took a sad song, and made it better
Remember to let it into your heart
And you will start to see it's better

Na na na na na ,na na na, p2'd ...

The Beatles - Hey Jude

Building Change

Seems everyone's talking about change these days. Hell, people are even ranting about the way media is changing.

But real issues aside, in part two of this series, I'd like to briefly mention two changes happening closer to home, here in releng-land:

• EMF, SDO, and XSD are now being packaged a little differently. Consider this a little social experiment to see who, if anyone, still uses zips to get their downloads, rather than using Update Manager. Do you like the new "sourcedoc" zips? Feel free to let us know what you think (here, on IRC in #eclipse-modeling, or in the newsgroups).
• GEF is now being built by the Common Modeling Build, the first (of many, I'm sure) projects to come over to the dark side. Will DSDP or VE be next? Time will tell.

Lies, damned lies, and a side order of acronym soup

By my calculations, EMF has scored over 2 million download requests since 2006-01-01. That's a huge number, but it's also an inaccurate number because our stats gen was broken for a while so there's a big hole in the Update Manager download stats. As such it's probably much higher, given the traffic we've had since the stats tool was fixed.

Looking at the overall numbers for all the tracked Modeling projects, we've had 5 million download requests since 2006-01-01 for EMF + M2T + MDT ... and that's just the Update Manager requests!

It's also fun to see who's downloading our bits. As expected, the US tops the chart, with Canada a respectable 8th. To get a sense for where EMF is used consider where the following projects are developed:

1. US: GMF, M2T-JET, WTP, TPTP, VE, ...
3. China: MDT-EODM, TPTP
5. France: EMFT, MDDi, M2M, GMT
8. Canada: EMF & EMF-QTV, MDT (UML2 & OCL), M2T-JET, GEF, GMF, WTP, TPTP, ...
12. The Netherlands: EMFT-Teneo
17. Czech Republic: GMF, MDT-UML2 Tools

To paraphrase Ed and the Zulu people, "umuntu ngumuntu MDD!" ;-)

EuroFM is on the air!

Europa Fall Maintenance is out today, so in tribute...

(Ctrl-) Space Down

Hey Eclipse you know you drive me crazy.
Ctrl-3 puts the rhythm in my hand.
Still I'll never understand how you can do so much
Plugins, features and such
Install Europa bundles from a mirror
Tell yourself it's so gonna rock your world again
You fire it up and then you swear a little

Do you feel like a geek
When you push its buttons?
Do you feel better now Ctrl-Space'ing a ton?
Well I'll tell you my friend no way this world's going to end
IDEs crumble down, they're eclipsed by this one

A pebble in the water makes a ripple effect
Every action in this world will bear a consequence
If you code by hand forever you will surely drown
I see what's goin' down.
Don't be a fool and use vi, emacs or notepad,
Startin' from scratch again,
Heed my lecture

Do you feel like a geek
When you push its buttons?
Do you feel better now Ctrl-Space'ing a ton?
Well I'll tell you my friend no way this world's going to end
IDEs crumble down, they're eclipsed by this one

In June '08 when we've all had enough,
Time for the Gany train!
[x2]

Do you feel like a geek
When you push its buttons?
Do you feel better now Ctrl-Space'ing a ton?
Well I'll tell you my friend no way this world's going to end
IDEs crumble down, they're eclipsed by this one

Downloadin' the code, she said, 'The mother lode!'
She said, I've finally found the best!
[x2]

Red Jumpsuit Aparatus - Face Down

10,000 Hits

Europa!
Europa!

One more download, yay! I know what I want
And my want will be an upgrade all right, an upgrade all right
Just another day when all that I want
Will mark me as an Eclipser tonight, an Eclipse geek tonight, yeah

[Chorus]
Jupiter's moons that can block out the Sun
If this disturbs you then walk away
You will remember: use -vmargs and -vm
10,000 Googlin' away!

Plug-ins un-restrained, dead on the mark
Is what we will deliver tonight, deliver tonight
"Features suck," they say, "but Update finally works!"
With even plugins tonight? Yes, even plugins tonight. Yeah!

[Chorus]

We are the ones that will open your mind
Leave the weak and the NetBeans behind
[x4]

[Chorus]

10,000 Googlin' away! 10,000 reqs per half-day!

Disturbed - Ten Thousand Fists

HOWTO: Install Eclipse for Multi-User Linux Systems

Here's my advice for installing Eclipse onto a Linux box shared among multiple users. I see three solutions with varying amounts of disk space use / user control.

1. Full User Control / Maximum Disk Usage

   Each user installs their own Eclipse in ~/eclipse. This occupies maximum disk usage (perhaps as much as 400M per user), but allows each and every user to configure what plugins/features they need in their Eclipse.

2. No User Control / Minimum Disk Usage

   Root performs a single central install of Eclipse in /opt/eclipse (or their distro's preference). Minimal disk space needed, but users have NO control over updates or of what plugins/features they have access to, just their private workspace(s) in their home dir. This means that if you have some CDT users and some PDT users, everyone will be able to do everything -- and all users will have the same pile of plugins loaded on startup, regardless if they ever use those plugins.

3. Hybrid Install: Partial Control / Medium Disk Usage

   Each user installs the Eclipse Platform Runtime Binary (~40M) in their ~/eclipse. All other plugins/features are installed into one or more "extension locations" in (for example) /opt/eclipse/modeling, /opt/eclipse/pde, /opt/eclipse/jdt, /opt/eclipse/pdt, etc.

   Users can then cherry-pick the feature groups (extension locations) they want depending on their needs via Help > Software Updates > Manage Configuration > Add an Extension Location, but can't run updates -- only root can. This means everyone's install *could* be the same, but you could also have Modeling users, PDT users, and PDE/JDT users who only have installed to their Eclipse the plugins they actually need to perform their job.

   

   If they need a feature that's not available in the common shared /opt space, they can install it themselves into a new extension location, such as ~/eclipse-plugins-phpeclipse. Then, if root notices that several users have downloaded and installed the same features, they could copy those features to /opt/ and symlink the users' extension location folder(s) to the common folders in /opt/ to save disk space.

In all three cases, I would also ensure that users have read the FAQ entries on starting Eclipse and tuning memory usage, so that as they add more features they don't crash their Eclipse or hog system resources. As root, it would be easy to create desktop shortcuts (and/or shell scripts) for a number of different canned Eclipse startup methods, using -vm /opt/jdk50/bin/java or -vm /opt/jdk60/bin/java, -data ~/workspace1 or -data ~/workspace2, and with -vmargs -Xmx256M -XX:PermSize=64M -XX:MaxPermSize=128M

This is how I would address this issue. How have other sysadmins solved this?

I did it all for the cookie...

No, seriously, I don't test for schwag, or for the cookie, though some muppets do. I test because I like to work on and with tools, sites, projects, frameworks... that just work, without jumping through hoops or needing to recite black magic incantations. (Which doesn't mean I won't accept schwag if people want to send it to me. So far the best schwag-like mail I've gotten has been a clown nose from Kim, but that's another story.)

Anyway, inspired by Ian's bad experiences today with Europa, I thought I'd try to reproduce them. I couldn't, but I got something IMHO worse. While there's ways to work around the problems I hit, the issue here is Newbie Usability. I've been hacking w/ Eclipse for 4 years. The point of Europa is to be easy to use for the first-timers, who don't know about things like the eclipse.ini file (I've never looked at that file until today) or any/all of the OSGi startup flags you can use.

So, to synthesize the Newbie experience further, I googled for "-Dosgi" and searched the Eclipse wiki, but the best I could find is passing mention of these flags in some 145 Eclipse bugs. Another usability issue, IMHO -- insufficiently quick-findable documentation.

Oh, wait, I think (while still wearing the Newbie hat), what about help.eclipse.org? Sure enough, it's documented as Eclipse runtime options. OK, that's cool, and that also means if I installed the SDK I have those docs in my Europa install, but if the problem is starting Europa in the first place, I still have to go hunting outside the Eclipse Help system. At least I've found what I wanted.

Back to the original problem... installing 121 out of 122 Europa features and watching as my Eclipse install crashes and burns on the first startup. Not cool. Second startup is better, but has problems on shutdown. Third time's the charm, apparently.

This whole experience brings to mind five, no, three questions, which I'll pose here and cross-post to the cross-project-issues-dev list too.

1. Should the Buckminster SVN support be contributed to Europa, or should it ONLY be on Buckmister's own Discovery or Update site, in order to avoid a config problem right out of the box? I'd suggest it should not be in Europa because of the negative perception it might cause both Europa overall and Buckminster in particular. It portrays two issues: (i) the full suite (122 features) doesn't work 100% out of the box, and (if you'll forgive the rather damning phrase), (ii) "it's all Buckminster's fault". I don't mean to offend the good folks on the Buckminster team, only to suggest what *some* might say, and how to avoid that perception from ever being voiced anywhere but this rant. ;-)
2. Since those who want SVN support need to add another Update site anyway (or install SVN features manually some other way), is it so onerous to ask those people to jump thru one extra hoop and remove the hoop from everyone else who doesn't need/want SVN?
3. Who in their right mind will need to install 121 features (451M) on day one of their Europa experience? I, for example, only really need about 75M of features on a regular basis (EMF, XSD, Mylyn, phpeclipse, PDE, JDT, CVS) on top of the base 40M platform (68M unpacked).

I agree with Michael Scharf (who, incidentally, was the only person who could follow instructions) that Eclipse can be compared to ketchup in that it's:

[U]sed everywhere. It often does not fit. ... It comes in massive amounts (like the 18 million lines of code of the Europa release). It's often hard not to use it.

But that said, I don't think installing Europa should be harder than banging on the bottle to shake the last dregs of ketchup down the neck and onto my fries. It's hard *not* to use Eclipse, true, but should it be this hard to *use* it too?

Request For Comment: Will anyone miss the EMF Standalone Zip?

With the advent of jarred plugins, improvements to Update Manager, and all the new smaller EMF 2.3 features (including 7 core "runtime" ones in Europa's Enabling Features category -- see bugs 106804 and 189295), the EMF team is evaluating if the Standalone Zip introduced in EMF 2.1 is still meaningful and useful to consuming teams, projects, and products.

For more on this topic and to learn what's actually in this zip, see:

http://wiki.eclipse.org/index.php/EMF_2.3_Standalone_Zip

To voice your opinion (be it 'I need that zip!' or 'not useful to me'), please post your feedback in bug 191837.

Thanks!

Managing Plugins and Features with Link Files and Extension Locations

After loitering and latering (but no lootering!) in IRC for a few hours today, I've come to the conclusion that not enough people know about .link files. I guess I could wiki this, but I thought I'd blog it instead.

Scenario 1: You're an Eclipse user. You use Eclipse a lot. In fact, you use multiple versions of Eclipse for testing, debugging, and even *gasp* developing. You waste a ton of time unpacking zips and running Update Manager.

Scenario 2: You use Eclipse and occasionally do something silly like deleting files outside of Eclipse or updating CVS files using commandline CVS instead of the click-click-wait method in Eclipse. (This is usually not a problem, but can sometimes lead to ...)

Scenario 3: Something Wicked This Way [Came] and your Eclipse has become corrupt. It's time to blow away your config files, .metadata files, or run with -clean. If that doesn't work you probably have to reinstall (oh crap) everything -- Eclipse + all your trusty plugins. You could also copy carefully from the busted Eclipse to the minty-fresh one, but that's both time consuming and possibly dangerous. Is there a better way?

Scenario 4: You produce a product based on Eclipse but want to keep your stuff and Eclipse's stuff separate when you bundle it all up for easier digestion by your users. Maybe for license reasons, maybe for legal reasons, maybe just for file system hygiene or to make support easier.

Scenario 5: You're a control freak and just like to keep stuff in different places according to your own particular... um... idiom.

In all of these scenarios, .link files can help. Here's how to set one up:

1. In your Eclipse install folder, create a links/ folder next to features/ and plugins/.
2. In your eclipse/links/ folder, create a textfile called whatever.link. This file need only be one line, with newline and no trailing slash(es), and can be called anything ending with .link.

   path=/home/nickb/eclipse/eclipse-plugins-phpeclipse
   -or-
   path=D:/eclipse/eclipse-plugins-phpeclipse
   -or-
   path=D:\\eclipse\\eclipse-plugins-phpeclipse

3. Unpack a zip full of plugins and features into the path specified in your .link file.

   /home/nickb/eclipse/eclipse-plugins-phpeclipse/
       eclipse/
           plugins/
           features/

4. Start up Eclipse. Check Help > About to see if all your plugins and features are listed.
5. Rinse, lather, repeat.

You can have lots of .link files and lots of install locations, which allows you to easily swap between different versions of plugins and features for testing purposes, or to share an install location between multiple Eclipse installs. And, when you upgrade Eclipse, you can just copy the old links/ folder into the new Eclipse and voom, all your old plugins and features are there. Please note that when changing between versions of Eclipse, sometimes things will end up disabled, if the new Eclipse won't work with the old plugins. If this happens, you can easily switch back to the old one, look for an update, or download a new zip.

You can also manage your plugins inside Eclipse. So, if you prefer clicking to typing, you can convert a .link file location into a Update Manager (UM) install location, so that you can use UM to install updates to plugins that you created by unpacking a zip, or just to reuse an existing folder for later UM installs. Here's how:

1. Complete steps above. Verify all your plugins & features are properly available in Eclipse.
2. To convert a linked folder to an "Extension Location" as used by Update Manager, you just have to put a single file in the eclipse/ folder inside the linked folder. Here's a sample:

   $ cat /home/nickb/eclipse/eclipse-plugins-europa/eclipse/.eclipseextension
   id=org.eclipse.platform
   name=Eclipse Platform
   version=3.3.0

3. Remove or rename the .link file that references the folder you just converted so that you're not trying to add the same plugins twice.
4. Start up Eclipse. Check Help > About to make sure you no longer have the plugins & features you just disabled. Then launch Help > Software Updates > Manage Configuration > Add an Extension Location to re-add those plugins & features.
5. Restart Eclipse.

Happiness in Codeslavery

Oh. My. God. It's over. Bug 106804, "rearrange the features to minimize external dependencies", is finally done. It's been quite the ride, as you can see in the bug. The last three days are a blur, but it's done. Marcelo and I have been fighting the good fight solidly from Tuesday until this morning to contain this change in time for the M7 + 1 deadline. Thanks to the PDE folks for providing invaluable assistance in deciding what paths to take. Pascal, Kim, Sonia, Andrew: you guys rock. Thanks also to everyone else I've bugged with 'have you ever done this with your features / does your project do this?' questions to determine if we were treading into impossible territory or following an existing path.

EMF now contains smaller features which can be installed via Update Manager to compose whatever legal combination you want. Thanks to Update Manager finally working with features' dependencies on plugins, you can use PDE to generate a feature's dependencies and have the Update Site actually work when you hit 'Select Required' to pick up all the associated required features and their contained plugins. (You have no idea how freakin' exciting this, and how long I've been waiting for this to work.) I still think features suck, but for now I'll allow that they suck a little less than last week.

So, here's the obligatory shout-out to the community to try out EMF 2.3.0M7, and let us know any issues you might have w/ migration & adoption. You can grab it from the usual places. Please don't hesitate to speak up in bug 106804: if there are any unforeseen migration pains, I'll use your comments to draft documentation explaining what's different, why, and how to roll with the changes next week after I've slept a little.

Thanks, everyone, and happy EMF'ing.