Thursday, July 13, 2006

Enablement now a project in DTP

Yesterday the Enablement passed creation review, which means that it is now an official project in DTP. As I described in an earlier entry, the PMC sees Enablement as a very important part of DTP's future, and is looking forward to working with various groups to build out wide and deep data source support.

I'd like to take this chance to extend once again an offer to the community: If you have a data source that you'd like to use in Eclipse, why not come and work on the Enablement project with us? There are many benefits to doing so, not the least of which is being able to work with a vibrant and talented committer community at eclipse!

Thursday, July 06, 2006

Eclipse Building Blocks

During last week's Eclipse Council meetings, we discussed evolution of the "base" eclipse build system to include additional features and encourage projects not already using it (such as DTP) to jump on board. I agree that DTP should be using as much standard eclipse.org infrastructure and best practices as possible, both since there usually are very good reasons (often based on hard-won experience) for the choices made and to provide a consistent context for those extending eclipse.

One thing I haven't convinced myself about yet is the complexity of builds. At eclipse.org we talk a lot about "transparency" (public discussions and decisions, etc.), and in general I think we do a good job with it. But builds tend to be a different creature. It goes something like this:

  1. Get code
  2. Magic configuration
  3. Compile
  4. More magic
  5. Build done!

In many projects I've worked on, only the release engineering team could do a build. No, I don't mean could == allowed, but could == capable. Any even then, if the stars were not aligned just right and the magic words were not spoken with enough gravity, the build wouldn't finish.

I don't think this is very transparent ("now you see this code, now you don't, here's the build!"), and that worries me for an open source project. Aside from the principle, there are practical reasons why tricky builds are bad: developers, whether committers on the project or not, should be able to get a code snapshot from source control, make minimal configuration settings, and have a build. Now, this might take a while to run, and sometimes you can't help that. But you should at least have the option. If I am changing/experimenting with some core functionality, I'd like to verify how it all hangs together in the build. (Doing so in a dev environment is good too, but there are many errors that can creep in between dev and "binary" environments too. Ever forget to update your build.properties file to include new resources?)

The build system for DTP started out with the main goal of "run for anyone," but with time and pressure, cruft slipped in. Going forward, we'd like to migrate to the eclipse "base" builder, but would also like to re-capture the "run for anyone" goal if possible too.

Any thoughts/experience out there? Anyone want to help DTP with this (I think it would benefit us all....)?