Eclipse bug reporting

I recently postulated the question: “Raising bugs against #eclipse - worthwhile or a waste of time? Discuss.” So I thought it would be interesting to see where my bugs were in the RESOLVED state, by resolution:

So out of the bugs I've raised over the years, half of them are fixed, quarter are DUPLICATEs, and the other are either ones that have been fixed already (WORKSFORME), ones that are not valid (INVALID) or ones that simply aren't going to get fixed, through ideolgy, compatibility or other such (WONTFIX). What the graphics don't show is whether those DUPLICATE bugs have been fixed, closed or other; but in my experience, the reason a bug gets marked a DUPLICATE is because it's been a long-outstanding problem and keeps getting reported repeatedly. A query suggests DUPLICATE bugs are fixed around 60% of the time, with around 25% of bugs still open. The remainder are misc items like WONTFIX, LATER, or WORKSFORME.

Perhaps more interesting is the overall proportion of raised bugs versus resolution. Omitting duplicate bugs (for simplicity), here's the results of my bugs:

There's certainly an inconsistency between how bugs are (or aren't) moved between RESOLVED->VERIFIED>CLOSED; but either way, the graphic suggests that 15% are still open (with ~5-10% being marked a non-fixed resolution like WONTFIX). On the face of it, then, it looks like the issues are being resolved. However, one item which is misleading is that bugs raised against older versions tend to stay old. A different report shows that my open bugs range over a variety of different versions, with Platform and JDT collecting the majority of stale bugs (i.e. those that are open against non-maintenance versions and likely never to be closed):

Putting that into perspective, some of these bugs are still marked as NEW despite being opened in 2002. My oldest NEW bug is bug 26814, although bug 26809 is in the RESOLVED NEVER category, and has had a number of duplicates raised against it. (bug 206113 was marked as a dupe in 2007, but sensibly re-opened since this feature was never fixed.) Although I've used Eclipse since the 1.0 days (and previously, the Visual Age series of products) as an IBMer, I didn't get involved in the Eclipse community until 2.1, which was when the initial Mac port came out.

So, what's the conclusions that you can draw from this? Well, even though there's a lot of open bugs in Eclipse generally, my personal response rate has been pretty good. There's probably more chance of the smaller projects being agile and fixing bugs than the larger ones, which tend to not be able to address all the issues in each release. If you've got bugs against the ECFs, XSLT, Mylyn type projects, then they're well worth filing; you'll probably get a good turnaround or discussion. Enhancements against some of the larger projects are the most likely to go AWOL; frankly, it's probably not worth raising an enhancement request against JDT or Platform unless you're prepared to supply a patch yourself (and even then, I've supplied patches to JDT to change sort ordering of members and kerberized CVS support which have gone stale due to being ignored for years).

Distributed version control systems and tools, like eGit, may help to prevent patches going stale in time. They may even help forking for fixing bugs that (for whatever reason) don't get fixed upstream; though obviously the desire is for forking to not happen. But the larger the upstream project, the less likely patches make it in from the outside world; and some teams are either in maintenance mode or just don't respond to changes any more.

Lastly; bugzilla triage and assistance from the community. There's a lot that could be done to help out projects which have a large amount of outstanding or potentially invalid bugs that could be cleared up by the community. Unfortunately, the current setup of Bugzilla is very much a partitoned, you-can-only-change-your-own-bug kind of model. That means that practically, you can't change anyone else's bugs, even when the bug may have been filed by someone else (or worse, when your bug is marked as a duplicate of theirs) whose e-mail address is invalid. The typical way of making changes is to add a comment suggesting that perhaps some features of the bug be changed (or marked invalid, or whatever). In practice, this is basically a waste of time (both of the triager and the committer who then applies that change). Not only that, but inter-team inconsistency in how Bugzilla is used causes expectation problems for the community who may use a number of different Eclipse components. For example, the RESOLVED vs VERIFIED vs CLOSED noted above is badly handled; some projects use CLOSED whilst others only get as far as RESOLVED. The version number of the bug is also inconsistent; when a bug is raised against a newer version (and then marked duplicate of an older version) doesn't help anyone. Who knows if a bug filed against 2.1 is still a 3.5 bug (like, for example, the packaging of Mac apps) if the version number is not updated? Yet there are projects who steadfastly refuse to update bug version numbers when any kind of filter will simply hide those from prying eyes. (The argument goes 'but we need to know what version it was raised against', but bug history shows you that. If it's really that important, perhaps a new Bugzilla field "First reported against" could explicitly record the initial occurrence of a problem whilst leaving the Version field to be updated when the bug is confirmed to be in a current version.) Sadly, I don't see this improving; there's a lot of inertia in the system; no-one wants to agree on a standard way of handling bugs; committers complain about volume of e-mail when you change things; hiding bugs by pretending they're old and irrelevant cuts down the amount of bugs that committers look at regularly; and lastly, Bugzilla itself doesn't permit changes easily or reduce the amount of minor noise that gets generated (like updating the version number of bugs).

So, is raising bugs worth it? Well, I like to think I've made a (positive) difference to the Eclipse platform, both on the Mac and all operating systems generically. Since I started raising bugs about 6½ years ago, I've raised 417 bugs, which works out on average around one bug every 17½ days. I've contributed some code to the platform (Project->PDE Tools>Open Manifest was mine, as was the Sort Members cleanup) but the majority has been finding issues or making suggestions about how the platform as a whole can be better. Sometimes I push hard for what I believe in; but in all cases, I'm aiming to make Eclipse a better and more inclusive platform. And, like Doug's hobby of Wascana, all my Eclipse work is hobby-based. I've not worked with Java for a good four or five years now; my day job doesn't involve Eclipse or any of its derivatives; and when I go to EclipseCon I have to fund myself to get there (and back). Oh, and writing for InfoQ (and before that, EclipseZone) about what's happening in the Eclipse world. And that's before any Eclipse-based hobbies like ObjectivEClipse or eGit come into play. And no, I'm not an Eclipse committer on any project.

So, to answer the original question: “Raising bugs against #eclipse - worthwhile or a waste of time?” It can be a worthwhile and rewarding experience. It can also be frustrating at times. There are improvements to the bug reporting (and triaging) process that could be done, and harmonisation of the way Bugzilla is used could be of benefit to the community as a whole. But taken as a whole, one person can make a difference and bugs (or patches) are the way to help.

Red Arrows over Milton Keynes

The Red Arrows flew over Milton Keynes (more specifically, Bletchley Park) as part of the Battle of Britain Memorial Flight (and the fact they were coming back from Southend's air show) but I caught them as they went smoke on and again as they banked away in big 9 formation.

Disabling Java in WebKit programmatically

If you're a sysadmin and you're worried about the recent security vulnerabilities in Mac OS X, here's how you can disable a user's Safari settings programmatically:

osascript -e 'tell application "Safari" to quit'
sleep 1
defaults write com.apple.Safari WebKitJavaEnabled -bool false

If you want to do this for all users on the machine, do:

defaults write /Library/Preferences/com.apple.Safari WebKitJavaEnabled -bool false

Note that Safari may overwrite the setting when it quits, so doing this once Safari isn't open is a good idea (hence the tell). If you have access to the network share where the user's preferences are stored, you can also overwrite them directly:

defaults write /home/users/a/alblue/Library/Preferences/com.apple.Safari WebKitJavaEnabled -bool false

It's also possible to grep the files for the string WebKitJavaEnabled (to see whether the string is mentioned there in the first place) although by default, the .plist will be in the 'binary xml' format that Apple loves. If you want to convert to XML, use the following:

plutil -convert xml1 com.apple.Safari.plist
cat com.apple.Safari.plist
<dict>
  <key>WebKitJavaEnabled</key>
  <false/>
</dict>

Lastly, if you've got a directory-controlled way of setting preferences (such as Workgroup Manager) then you can set a policy to disable it directly. dscl is your friend here; you can import MCX records. Dump this as a String into the mcx_settings key:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>mcx_application_data</key>
        <dict>
                <key>com.apple.Safari</key>
                <dict>
                        <key>Forced</key>
                        <array>
                                <dict>
                                        <key>mcx_preference_settings</key>
                                        <dict>
                                                <key>WebKitJavaEnabled</key>
                                                <false/>
                                        </dict>
                                </dict>
                        </array>
                        <key>mcx_targets</key>
                        <array>
                                <string>user-managed</string>
                        </array>
                </dict>
        </dict>
</dict>
</plist>

That will ensure that any user inheriting those MCX settings can only ever have this setting of disabled. But there's an easier way of doing this (if dscl is configured and authroised to make changes) - you can run:

dscl /Local/Default -mcxset /Users/alblue com.apple.Safari WebKitJavaEnabled always false

Of course, /Local/Default is the name of the local machine's directory – if you've got an LDAP server then it'll probably be something like /LDAPv3/ldap.example.com; and your username will be different, too :-) MCX settings can also be changed on a computer (or computer group list) as well, but that's outside the scope of this post.

Hopefully, you should be secure in surfing from now on until Apple gets their act together and kills secures Java.

How Apple killed Java

Despite the potential to benefit Apple more than other operating systems, Java has been a bit of a millstone around Apple's neck for a while. It's sullied Apple's name and caused it much grief from its developers, and to some extent even alienated a few whose Java work is their business. (Worse, none of this is Java's fault – it's all firmly on Apple's doorstep.)

But Apple, whether intentional or otherwise, has managed to kill Java. From its promising early days to shipping Java with every Mac (and making the JavaVM.Frameowrk available to all and sundry), combined with its support for WebObjects and associated Java-developed NSClasses, Apple has now firmly given Java, and by extension Java developers, the boot.

It's actually been a long, drawn-out, slow death rather than a quick-and-easy execution. Let's see where it all started to go wrong:

• Apple drops support for frameworks in Java Bridge considered legacy. Primarily aimed at a sales tool when WebObjects was being outclassed by heavierweight Java EE application servers, the Java bridge allowed Java developers to take advantage of Mac UI components to build applications. Great idea, and the underlying concept lives on in the form of the Objective-C bridges to Python and Ruby (and even powering the Cocoa port of SWT). However, one of Java's attractions was its run-anywhere model; so on the one hand, the Java purists (100% Java, anyone?) wouldn't touch it with an NSBargePole, whilst people who 'got' Objective-C wrote in that instead. There was a pretty small user base for both of the WebObjects customers, to the extent that WebObjects — once a $50,000+ product in the NeXT days — eventually became free and integrated into Mac OS X itself, and ultimately begat the CoreData API
• Java 6 released late and only for 64-bit Macs. Despite there only being a handful of 64-bit macs in the wild at the time, Java 6 was previewed in December 2007 and released in March 2008; despite being available since December 2006. Even the preview was a year out of date by the time it happened, and by the time it was released to Apple users, Java developers had already given up in disgust. Of course, the 64-bit only strategy was based on Snow Leopard's 64-bit only support (almost certain to be Intel-only 64-bit support) but unfortunately the OS has been taking the same leisurely pace as its Java 6 cousin.
• No Java on the iPhone. This was the real killer for Java (though not, as pundits thought, the iPhone). There's actually two angles to this:
  1. Because there's no JVM, applications are compiled 'to the metal'. Difference between execution speed on a good JIT and an equivalent C program have fallen to the wayside on fast GHz systems; but a lower-processor spec item like an iPhone it's more noticable (and probably without a JIT). Doesn't mean it can't work, as googling for JamVM will show you. Of course, the real reason was in application prevention so that Uncle Steve can vette your apps instead of you installing them yourself. But also;
  2. It forced developers to learn Objective-C. Frankly, any language is pretty much like another for the purposes of getting things done, but by making only one of these possible (no python, ruby etc.) ti brought a bunch of developers to the Objective-C kool-ade fountain. And now that they've tried it, in most cases, they realise that they like it. Even things like Garbage Collection have come to the Objective-C stable (though OK, not for the iPhone OS yet) and it was good. The iPhone has been the biggest advertisement for Objective-C than all the macs in the world put together; and people are flocking to the platform. Who cares about other languages when you can support your own?
• Fanatically dangerously late security patches for Java. The January 2009 update plugged several holes with remote-execution capability from Apple's JVM implementation; and now, we've got much the same problem, except that this one has been known for six months. And yet still no update from Apple. The only sensible thing (other than removing old versions of Java from your Mac) is to disable Java completely. Single-handedly, Apple have managed to turn everyone off of Java by making sure that everyone's got it disabled at the client layer. (Well, not that anyone uses crapplets any more; but a few might use Java WebStart, which is also fingered in the security hole.)

So, Apple has managed to kill off Java on the Mac, mostly through incompetance, slightly through focussing on the 64-bit as an upcoming marketing strategy, and largely through promoting Objective-C via the iPhone. But let's not let our good friends at Sun JAVA Oracle not share some of the blame for the fiasco that is Java's crumbling development model. By tightly welding the JVM, the libraries (as one über-massive turdfest) and naming conventions that have a new naming convention every release, Java has been a monolithic release train heading straight to the scene of the accident for some time. Consider where Java would be on the Mac now if the JVM had been spun off in the 1.2 days, and the libraries had evolved their own paths since? Chances are, a lot of the 'good stuff' (multi-threaded collections, internationalised domain names, ws-death-star implementations etc.) might even be downloadable as 100% pure Java modules. Hey, it works for Python and Ruby and pretty much any OSGi application and Maven ... Sadly, Sun JAVA Oracle lost the plot a long time ago on the whole JVM vs Java compiler vs Java libraries thing. OSGi helps, and the recent revitalisation of the Java modularisation stuff (sorry, JDK7 modularisation stuff) is a good step in the right direction; but it's a bit like bolting the stable after the horse has been put down.

Sadly, Apple's marketing of PCs as being more secure than Windows stand up to little scrutiny, and Java (as an open-source but six-months-behind product) is a vehicle for ramming viruses up where the Sun no longer shines. I expect now they've been publicly embarrassed to respond with a fix; but who knows how many other security holes are lying in wait? Would you even want to find out? Chances are, the next version of Safari will come with Java disabled by default - and then Apple's Java will be dead to all.

Why do (Eclipse) bundles start at 1.0.0?

Eclipse's plug-in bundle development environment makes an assumption that all bundles, everywhere, should start at version 1.0.0 whether that makes sense or not. Even the well-documented version numbering document lists 1.0.0 as an example, and that has been assumed to be the de facto standard.

The problem with this approach is that not everything starts out life as a 1.0 product. Not only that, but OSGi's versioning scheme is an ever-incrementing one; once you go 1.0.0, you can't go back. As soon as you release code with a 1.0.0 version, you have to keep incrementing the version from there. And if it's something as a work-in-progress — like ObjectivEClipse — then potentially confusing users with a 1.0 moniker on a clearly alpha product won't do you or your product's reputation any good.

At this point, it's worth taking a step back to observe a few things:

• 0.0.0 is both the 'default' version (if one is not specified) and the lowest number you can have, as per the OSGi spec. From this number, you can go up to any version you want, but there's no down to go to.
• The suggested versioning use (both by the OSGi spec and Eclipse's version numbering scheme) is to treat major breakages as an increment to the major number (first digit); any new (but backward compatible) externally visible features are an increment to the minor number (second digit), and any patches or updates are an increment to the service number (third digit).
• Initial versions of items are never, never complete. Unless the code has been developed in-house by a coloured company and then donated to Eclipse en-masse, all code starts with a single line. Pretty much every build cycle will introduce new features; backward compatibility is something to hope for rather than a solid guarantee; and what you end up with for your first release almost never ends up looking like it started with.
• The Eclipse versioning system, whilst comprehensive, isn't really followed by the integration (or nightly) build process in any case. In fact, all the distinctions between different bundles use the lexicographic qualifier, with an encoded date format, against the same OSGi version for most of the build. If lucky, this will be upped just prior to the release train instead of as a delineating factor during development. Partially, that's so the final Eclipse version (3.4.1) corresponds to the version of the bundles when the release candidate happens.

So a lot of how PDE works, and how the bundles are built, are direct artefacts of how Eclipse's release engineering train works, rather than actually following separate build streams for individual bundles. Quite a lot of that is based on the date encoded in the lexicographic qualifier; if the versioning was being followed for each integration build, you'd expect each minor service* version to be incremented if following the versioning document explicitly. (At this point, an argument will break out about whether (a) the interim products (nightlies, integration) should even be versioned, or (b) having such dependencies would allow consumer bundles to demand at least a minor level to absorb bugfixes, or (c) whether Eclipse's release train process/tools are something one should copy. Feel free to discuss; they're not relevant to the point in hand anyway.)

So, if PDE is trying to lose its P moniker and end up with a B moniker instead, why doesn't it default to creating bundles with a 0.0.0 qualifier? Bug 277082 is open for comments, though this late in the release cycle (you know, the one where you're supposed to be testing for and filing bugs) is pretty much guaranteed to be ignored for Eclipse 3.5. I almost fell for this in the 0.1 milestone release for ObjectivEClipse, and just when I was generating the non-p2 enabled update site (i.e. it works) I discovered that I'd unwittingly created a 1.0.0 monster. I plan to add more new features that are externally visible in the next milestone, so going from x.y.z to x.y+1.z was always going to happen anyway, but starting from 1.0.0 is a bit of a historic artefact from the pre-OSGi days.

Lastly, even Eclipse 3.5 has some 0.x.y versions buried in it. ECF's bittorrent provider is at 0.3.x (at least, as of Eclipse 3.5M5 which I have on this machine - might have moved forwards since) and the JSch bundle (used for secure shell) follows the developer plugin version of 0.1.x as well. So basing the 1.0.0 on "that's the way we do it" doesn't really hold water - there's nothing in the version numbering document that mandates an initial 1.0.0. In fact, probably the only reason why there are so many 1.0.0 bundles in Eclipse is purely to do with the default in the PDE UI that makes a 1.0.0 the initial starting point from which you can never go down.

* Update: thanks to Ian Bull for pointing out I meant 'service' instead of 'minor' in the integration builds

Remove old versions of Java from Mac OS X

I recently discovered that Mac OS X has a plethora of old versions of Java, installed by default, on Mac OS X. /System/Library/Frameworks/JavaVM.framework/Versions lists many ancient versions of Java, including those with known security holes. Given that both 1.3 and 1.4 are already End-of-Life (and the fact that everything will run on 1.5 or above), there doesn't seem to be a particularly compelling reason to keep them around.

In order to remove stale versions of the Java framework from your machine, execute:

sudo rm -rf /System/Library/Frameworks/JavaVM.framework/Versions/1.{3,4}*

For example, the buffer overflow in GIF processing for Java earlier (CR 6805998) affected not only current versions of Java, but also past versions as well. However, given that 1.3 and 1.4 are not being actively used any more, having them around invites an attack on Mac systems through use of (say) Applet tags that specifically request a 1.3 VM, or Java-based applications that request a 1.3 VM.

As usual, caveat emptor and once you start mucking around with stuff in /System, you're on your own. Having said that, Apple publicly ignored the do-anything-as-root Apple Remote Desktop vulnerability, it's not clear how long it will be before older versions of Java will get patched. In the meantime, there's no harm in protecting yourself against the possibility of a remote attack via use of stale versions of Java by removing them from your system.

Update: The Register has details of the security blunder

EGit project review successful

The EGit project proposal has successfully passed review, and is now awaiting provisioning. Hopefully this will unlock the door for the code to be moved from its current home (at Google Code) to a new Eclipse home instead. Development continues in any case, and hopefully we'll be in a position to start having automated builds kicking off and generating update sites for those who want to live on the bleeding edge.

At the moment, there's no immediate timescale for the move, but since there will be a lot of refactoring work (as well as firing up a new Git repository on the Eclipse.org infrastructure) it might take a while to move. Watch this space ...

First (and last) thoughts on Eclipse 3.5M7

Over the long weekend, Eclipse 3.5M7 was released. This is the last in the milestone series before the June release for 3.5. Between then and now, we have a handful of release candidates aimed at squashing bugs rather than adding any new features.

Given that I'm (slowly) working on ObjectivEClipse and working on EGit at the same time, I want to have a stable environment whilst also basing off the latest versions of the software, not least of which is to verify bugs have been fixed which ObjectivEClipse depends on. So, off to download 3.5M7 ...

The problems started when choosing a download for Mac. There's two versions available - one for Cocoa and one for Cocoa-x86_64. Mac users aren't accustomed to platform-specific downloads; after all, the Mac's fat binary format allows multiple architectures to exist in the same binary at the same time (aka Universal binaries). This has been used to support G4 and G5-optimised builds in the days before the intel switch, as well as supporting both the PPC and Intel builds since.

So why do we need to have a separate platform for Mac at all? Well, the SWT binary has an implicit dependency on the size of the pointers returned by the underlying native layer, and uses either int or long appropriately. So, the Java code, which deals with pointers, needs to be able to accommodate both variants. In order to do this, there's a SWT hack convention which uses a replaceable int/long combination, and there's two versions of the Jar that are built; one that has long pointers, and one that has int pointers. (If you've ever looked at the source code for SWT, you'll see things like private int /*long*/ ptr - a post-processing system reads in the source, swaps the comments, and then compiles it.)

OK, so having an x86_64 laptop, I download the x86_64 build. Seems reasonable enough. Eclipse launches, there is much rejoicing etc. However (and here's the cunning bit) Eclipse then fails dismally to be able to launch itself in a runtime Eclipse application, complaining with an error 'You must use a 64-bit JVM to load 64-bit SWT' or similar. Hang on - a running Eclipse instance is telling me that Eclipse can't run? Despite massaging the target.arch platform to get it to run x86 instead of x86_64, no dice. And it hosed the workspace, so I've had to roll back to a previous version (thank you ZFS!).

Unfortunately, that wasn't all my timewasting. In order to get to that stage, I had to re-download all the plug-ins that I needed to get up to speed, which included Mylyn, the Mylyn incubator web connector (which doesn't seem to have done much incubating recently - stick it in the main download, why don't you?) in order to hook up with google code as well as the real SVN plug-in, subclipse. Remember the good old days where you could have a separate plug-in install location? Good ol' P2 thinks you don't need that any more. Despite it being technically feasible to have more than one plugin repository, no-one seems to know how to do it, least of all the P2 wiki. In fact, earlier conversations seemed to suggest that whilst it was technically possible, no-one has tried it and thus it actually is buggy at the moment.

What really grinds my gears is that the new P2 update manager appears to go out of its way to prevent you from updating. Case in point, the above subclipse download. Plugging the http://subclipse.tigris.org/update_1.6.x update site into the update manager gives you the 'subclipse' category; if you select that, you get the combined set of the below features. However, the category includes both Mylyn 2.x and Mylyn 3.x support; great for people who might not have migrated to the latest and greatest whilst still providing support.

Alas, no, the P2 update manager requires you to have both Mylyn 2.0 and Mylyn 3.0 installed if you want to install everything from here; the cryptic 'Some constraints cannot be satisfied' message and the Finish button disabled. Were one to press the 'back' button in some misguided attempt to fix the problem (like deselecting the Mylyn 2.0 feature), the 'finish' button is dead in the water and refuses to move thereafter. You actually have to quit the update window, re-open it again, plug in the update site ... remember to deselect the 'Mylyn 2.0' feature, and you're good to go. Repeat ad nauseum with the other features you may have installed (google code web/mylyn plug-in, check style etc.)

What's mind-bogglingly clear is that no-one actually uses the update manager at Eclipse in order to update Eclipse. Initially, you could excuse the whole newness of P2 as explaining away any quirks; but frankly, even P2 was released too early last time around, and the update story hasn't got any better since. Witness the sheer number of .zip files that the automated build processes spit out on a daily basis (and the mirrors around the world who swell up holding redundant copies). How many copies of org.eclipse.osgi are there? com.ibm.icu? org.eclipse.swt, of whichever binary build you have? Partially, this is due to the success of the EPP, which pumps out near-identical base builds with a different topping for the major use-cases of Eclipse - but realistically is the only way to get hold of Eclipse due to the state of play with update manager.

Participation in the Gallileo release train has a Must Do requirement for a P2-enabled update site. I've yet to see a project publicly put up a P2-enabled update site for updating Eclipse's M builds; I'm willing to bet that the majority of the Eclipse team simply download the latest version spat out by one of the build processes. (Mylyn is a notable exception; they have a weekly update site which I suspect most Mylyn developers will be hooked up with.)

I'll go further and say that Eclipse should stop building .zip bombs of the Eclipse platform. All we need is one (or a handful) of .zips containing the platform and update manager with some predefined (preferably small number) of update sites. If we want to install Eclipse, download and run the updater. One could very well argue about the contents of the minimal bootstrapper, but there should be one. Downloading new features should be a point-and-click exercise, not an exercise in Google site searches. And how about a combined repository for Gallileo artefacts, instead of a per-project URL? Maven has shown - for years - how this can work well, and Eclipse would do well to follow its lead. For example, a single directory of every plugin ever made, with the requirement of having a single global site.xml (or whatever P2 flavours you end up with) isn't a scalable solution. Not only does it suck if you are trying to find something, it's also a write-once repository; once you generate that site.xml, you're off to a losing start. Any changes, even if they're there on the web server, won't show up until it's regenerated. Maven has built up a well defined directory structure, so if you know what you're looking for, you know which directory to look (and then find a per-directory config, not per-repository config). One could expect a Mylyn bundle to be in org/eclipse/mylyn, for example.

Unfortunately, in the present, there simply is no good way to do updates from Eclipse using the built-in tools. Because of that, people shun using the update manager and download megabytes of bits every time, even if they don't need to. P2 focussed on the wrong problem (Wahey! We can install 17 copies of the same application from a single local cache of bundles!) instead of focussing on making Eclipse an updatable application. Granted, there are some technical advances (using pack200 compression for the Jars, for example) but it's all plumbing and no porcelain at the moment.

Anyway, I've given up with Eclipse 3.5M7. Not that there's no features, or that I don't want to help out testing, but simply because It Just Doesnt Work. Installing into Eclipse is a waste of time; downloading zips and then copying the contents (manually) into plugins/ and features/ (which incidentally, are still pretty oxymornic concepts; we're in the 'bundles' world now, and everything's a bundle) is about the only workable solution. Until Eclipse stops dumping out .zip bits and starts consuming its own update sites, it's not going to get any better.

PS http://ondemand.yoxos.com/ gets it better than Eclipse Update does; however, after pick-and-choosing your favourite features, it still serves it as a giant zip blob. However, once you've got it downloaded, you can then consume additional features subsequently in incremental update forms. It's just a pity that they only support the 3.4.x streams rather than having a way of testing 3.5Mx streams.