We shoemakers are typically so busy making shoes for others that we and
our children are often out and about in shoddy shoes if not
barefoot.
There is also a strong tendency in the wider Eclipse community to find fault without taking action, looking instead to others to magically fix problems while feeling entitled to "motivate" those actions with poisonous
complaints.
We should consider carefully what's wrong with this picture.
Consider for example the all-important
Eclipse Platform project and the perennial concern
about the limited contributions it receives. Of course this same
concern extends to all projects
—we'd all love high-quality
contributions associated with each and every Bugzilla report
—but let's
just take the platform as a case in point. Suppose you would like to provision an
IDE for working with the platform SDK source so you can commit your bug fixes to
Gerrit. All you need to do to get started is follow
a few simple steps.
That's right, in the modern age of integrated development environments,
you're expected to act as an interpreter for converting human language
scripts into machine operations. Does that not strike you as
completely anachronistic? Of course you're likely already doing this each time you provision an IDE to work on your own project, and you likely don't keep up with the release train milestones because it's a royal pain to do all this work each time there's a new version.
This whole problem irritates me to the extreme, not so much the
platform's specific problem, but the fact that I have the same problem
for EMF and for every project I use and to which I wish to contribute. Just so you don't think I'm throwing bricks
at the platform, have a look into my glass house, in particular at the extremely
lovely analog of the platform's wiki page for
setting up EMF's source.
Good luck getting that to work! What that heck is CVS?
Not only is it
anachronistic to follow scripts manually, it's always the case that
these scripts become dated and are in need of constant maintenance, which,
as busy developers, we don't have time to do. Compound that with the fact that
the scripts are buggy, you should not be surprised that when you treat the community like monkeys, you end up mostly with a lot of hooting.
Oh well, so much for the whining, sniveling, and complaining part, this problem calls for action.
Eike
and I, being inherently lazy, don't even want to follow these kinds of scripts
ourselves so we've worked on
an alternative approach.
Yes, there's still
a script for bootstrap purposes
—you can help improve it
—but here's the synopsis:
- just as you would any Eclipse
package, download the appropriate version of the
Eclipse Oomph installer—we need to do some brand marketing instead of just calling it the "Setup tool",
- unzip it,
- run it,
- select the project you wish to set up,
- go for
coffee,
- and come back to enjoy your fully provisioned IDE along with that
fresh cup of Java.
Here's how you'd provision an IDE for working with the platform's SDK:
Here's the end result:
Of course a workspace with the entire Eclipse SDK as source is a bit aggressive, but it's a great proof of concept that it can be done for the entire platform. Be patient though, Rome wasn't built in a day: the platform's code base is very large, so cloning it all takes time, for me more than an hour! Try a simpler project, like the EMF Core SDK, if you want more immediate gratification, and keep in mind that this would not be any faster if you did it manually. Note that Oomph was built with EMF. Did I mention that we're inherently lazy?
It's quite easy to author an executable setup script for your own project. Here's how the platform's setup script looks:
The platform's script is quite complex because the platform itself is complex. Not only that, there are gotchas to get the platform to build without errors, e.g., an inherent need to install several JREs, which I avoided by changing project-specific preferences to not treat an imperfect JRE match as an error. You can see there are tasks to set global preferences, a task to install additional tools, e.g., the EE profiles feature, tasks to clone the dozens of repos, a task to materialize the target platform, a task to populate reasonable
dynamic working sets, and so on. Unfortunately it's apparently very hard to build all the platform's Ant jars and there appears to be a platform bug that requires an IDE "Restart" followed by a "Build All" before everything builds without errors and with less than 17,000 warnings. Note that the provisioned target platform contains only bundles from Orbit and from Jetty; I have no idea how the Jetty folks provision an IDE to work with source.
Eike and I intend to maintain an index of all Eclipse project setup
scripts so that our community of contributors can enjoy one-stop shopping. In
addition, there are already folks looking to maintain indices for other
open source forges.
The script-authoring documentation is a work in progress,
but of course you can look at all the working examples as a basis for creating your own; remember to turn on "Live Validation" in the editor to catch problems early. Note that if you provision the CDO Release Engineering environment using Oomph, you'll have all
of Oomph's source code and some
example scripts at your fingertips. Contributions to the project are welcome; your changes can be easily committed to Gerrit.
If you have questions, please use the
EMF newsgroup and prefix the
subject line with "[Oomph]". If you find problems, please report a
Bugzilla. And finally, if you're so inclined, come see our
EclipseCon presentation!
As you might expect, we're not the only ones who recognize the need to solve this vexing problem nor the only ones with a solution for it. If you need this same type
of thing in an enterprise context, you'll want to have a look at the
cool features of
p3, e.g., carefully managed inside-the-firewall p2 repositories.
As a footnote, it's committer representative
election time again. How
will you decide how best to cast your vote given the 4 available
choices this year? Of course you'll want people who
actively represent your
committer interests at Eclipse, so you might glance at
commit stats to see who's actively committing to notice these lines-of-code-committed stats over the past 1, 3, 6, and 9 months:
As a caveat, keep in mind that modeling is a great productivity amplifier! Not only that,
code commits are not the only significant committer activity and are mostly certainly not a good measure of who will best represent your interests.
On that note, I can only promise that, if elected, I'll continue to do my best to
make sure Eclipse is a great place to be. You can definitely count on me to take action where action is needed.