Builds have gotten better with the arrival of the Athena Common Builder. I know first-hand how much easier it is to get a build running as I’ve applied it to some of the projects that I’m working on. Numerous projects have adopted Athena and seem to be thriving on it. This is, of course, largely due to the tireless efforts of Nick Boldt (who has recently been brought into the Architecture Council). We’re still not to the point of having a single Ant or Maven script, but it is getting better. New work around build is on the horizon in the form of the B3 project.

I recall the first answer to the request for Git repository support at eclipse.org: “no way”. Today, we have a Git mirror of our CVS servers and are on our way toward implementing a proper Git repository for a few select projects sometime early in the new year. Denis “Scotty” Roy is, of course, working his usual miracles. It won’t be long before we have first-class support for Git both as a repository and as integration with the Eclipse workbench via the EGit project. On that note, first-class rock-solid Eclipse-based tools for Git is one of the conditions for full-blown Git support at eclipse.org; please get involved with the EGit project and help where you can.

Early discussions about Maven repositories at eclipse.org didn’t get very far. But, thanks to the good folks from the Buckminster project, we are planning to make the Helios release train available as both a p2 and a Maven repository. Over the past couple of weeks, I’ve been chatting with many folks in our community about creating a new über repository where projects that are not participating in the release train can make their code available to both p2 and Maven clients. The best part in all this is that it doesn’t require very much work for projects to participate: it’s looking like they have only to make their update sites known to the aggregator and they’re in. The aggregator will do important things like check dependencies and keep track of previous versions; these are important features for people who depend on bits staying where they are so that they can base real builds on them. Having an über repository will make it far easier for the broader community to find and use Eclipse technology. We’re still early in this process, but I remain hopeful and excited.

And darn it, we’re going to get Bug 280730 resolved.

It’s amazing what a little positive energy can bring.

You can set the iplog flag on an attachment. This is probably the most natural way to use the flag. To set this flag, open the “Details” for the attachment, set the value to “+”, and commit. That’s it. Do this for any attachment that contains something that you’ve committed into an Eclipse source code repository. This includes things like code patches, image files, XML schemas, and pretty much anything else. Only mark those attachments that actually make it into the repository; just leave any other attachments alone.

You can also set the iplog flag on an entire bug. You would do this if the bug’s summary or one of the comments contains code, or some other valuable asset that you commit into the source code repository. Unfortunately, flagging the bug indicates to the automated tools that every comment on the bug is a potential contribution (sadly, it appears that there is no way to set a flag on an individual comment). When you set the flag on the entire bug, you have to manually go through the generated log and remove any comments that shouldn’t be there. Yes, this can be painful. It’s made more painful by the fact that any new comments added to the bug after you’ve done your clean up will appear the next time the log is generated. This is particularly troublesome in the current Automatic IP Log Tool, and only slightly less so with the new one.

The bottom line is that it is always easier if your contributions come in the form of an attachment.

Only those attachments and bugs that contain contributions from developers who are not committers on the project at the time need be flagged. This is time-sensitive. If the contributor eventually does become a committer, those patches they’ve contributed while they were not a committer still need to be accounted for in the log and must therefore be flagged. The tools are smart enough to check the dates. Make sure that each committer’s Bugzilla email address matches the one in the Eclipse Foundation database, or you’ll wind up with some extra stuff in your IP Log.

I’ve been thinking a lot about communication lately. More specifically, I’ve been thinking about the utility of sending notification emails. We send an email to notify the membership of new project proposals, up-coming reviews, and other such things. Are these emails actually useful? Do they end up in your “Junk” folder? Do you read them and say “I have got to get me one of those?”

Our “What’s new” page contains all the information you need to keep up with the project proposal and review activities. There’s even an RSS feed for it. I was starting to think that this was enough. But this morning, I received two responses to my recent email announcing the Doc2Model proposal. So, clearly somebody is reading the emails. I suppose that we could also set up a Twitter feed of some sort, and maybe blog more consistently about these events.

In any case, it’s all about the community. It’s all about making sure that everybody gets a chance to participate. I just don’t want to be part of the conspiracy.

I look forward to seeing everyone at Eclipse Summit Europe next week!

I wish this was happening after Eclipse Summit Europe. If it were after the Summit, I could apply some of the wisdom from Steffen Pingel’s Effective Mylyn talk to my own.

See you all at the Bootcamp and/or Eclipse Summit Europe

I discussed this article a few posts back. In that post, I discussed some technology that I’ve been tinkering with to help sort out how to find the project that contains a particular class in Eclipse CVS or SVN. This information would make it very easy for a would-be contributor to obtain the project, and build a patch. That tinkering has progressed a little, and I am now able to generate an XML file describing the mapping. The challenge right now is that it takes a very long time to run. I’m going to experiment a little with adding some threads, since I’m pretty sure that it’s spending most of its time waiting for information to come back. It probably doesn’t help that I’m using the internal CVSFileStore which was never really intended for this sort of use.

Soon, I hope to make an XML file available so that you can tell me how useful this really is. Other good options for dealing with the problem have been discussed (e.g. Alex Blewitt, OSGi Bug 48, and Bug 243582). This solution has the benefit of not requiring any work by project committers, but suffers from the fact that it is limited only to bundles hosted at eclipse.org (though, there’s no reason why it can’t be pointed at other repositories).

I’ve just learned that my poster session for Eclipse Summit Europe has been approved. I’m looking forward to showing off this technology and getting your feedback. See you there!

A lot of projects are opting to just adopt their parent project’s plan. One obvious example is the Eclipse Project: most of the projects that fall under the Eclipse-top level are sharing the plan assembled by the Eclipse PMC. This is all about letting the community know what the project is doing, and sharing a plan is a fine way to do that: so long as the shared plan actually makes sense.

The Web Tools Project is taking a slightly different approach: each of the projects has its own plan, but defers to the parent project for release milestones. This, unfortunately, makes it a little more challenging to use automation to determine if the plan is valid, but it seems like a reasonable way to do things, so we’ll adapt. I’m considering adding a notion of inheritance to the project plan XML Schema to address this.

For the overwhelming number of projects that have their plans in order: thank you. For others, let me know how I can help.

Project leads and committers: if you want to meet with me at Eclipse Summit Europe 2009 to talk about project plans, the Eclipse Development Process, or anything else, please let me know.

The first thing you see when you use the tool is the wizard. The wizard can populate a new IP Log with information gathered from the various Eclipse Foundation databases. As you can see from the screenshot, the user is presented with a hierarchical list of all Eclipse projects (the list itself is pretty impressive).

Here, I’ve selected the eRCP project from the Eclipse RT top-level project. When the user clicks “Finish”, the wizard makes a call out to a web service running at the Eclipse Foundation to gather all the necessary information. The results, which are saved in a file in the workspace, are displayed in the editor.

Many readers will recognize that this this editor has been generated using EMF. With almost no work, the editor is completely functional (with help from the Properties view). I’ve fiddled a little with what was generated. I’ve created a couple of icons, changed the way that some of the objects are labeled, and that sort of thing. You can also see some evidence of a custom “Committers” page that uses JFace Databinding, I’ve started poking at. I envision eventually having a page for each part of the IP Log (committers, third-party contributions, contributors and their contributions, etc.) with the “Selection” page or something like it relegated to the back of the editor’s page stack.

I think that some customized pages will make it easier to use. In the meantime, it’s very cool that EMF has generated a fully functional editor.

One of the bigger challenges of maintaining an IP Log is keeping it up to date. This is where EMF Compare comes swinging in to the rescue. With EMF Compare, I’ve added the ability to compare what is captured in the log against the information found in the Eclipse databases, and selectively update the log with those changes. The best part is that I’ve been able to just reuse the same web service that I used to do the initial population of the log. No, scratch that, the best part is that I’ve been able to implement this compare and update functionality with a couple dozen lines of code.

Here’s what the compare editor looks like after I made a few changes to the initial log:

Right now the compare and update works directly out of the editor. Eventually, you’ll be able to do the compare without even opening the log (I’m not sure how useful this will be, but it’s only a few lines of code). Note the “Copy current change from right to left” icon, , above the “Eclipse Foundation Databases” panel that users can employ to make updates to their log. I’ve disabled the functionality that permits movement from left to right: at least for now, Eclipse Foundation Databases cannot be updated using this tool.

There is still much work to do, but I am encouraged by the fact that it’s already useful. I’ll be demonstrating the tool at Eclipse Summit Europe 2009. Assuming that the poster session I proposed, “The Eclipse Development Process“, is accepted, I’ll be showing the tool there. That failing, I’ll just demonstrate it to anybody who will listen. My intent is to contribute it to Dash after the summit.

I’d like your feedback on the concept and, of course, the implementation. Personally, I think the idea of tools for committers built using Eclipse Technology, run within an Eclipse environment, is brilliant. I hope you do as well.

For the curious: The data returned from the web service is in XML format. I created an XML Schema that I used to generate the EMF model. I used standard EMF tools to generate the editor. For the time-being, this tool assumes that the log will be stored in XML format somewhere in the project’s “web” CVS where it can be easily retrieved. At some point, we’ll need to make an XSD that translates the log into a more human-friendly HTML form.

My hope is that I’ll be overwhelmed with your input and that we’ll be able to turn this into a useful tool.

Good planning is an important part of every Eclipse project. A project plan sets the direction of the project. It lets the committers know what sorts of things they should be working on. It lets the community know how and where they can add value with their contributions. It lets adopters know what to expect when they’re building products based on the technology produced by the project. In short, the project plan is a critical part of reaching out to and developing the community and eco-system around a project.

It is also the case that having a project is a requirement for all Eclipse projects. The Eclipse Development Process, section 5, has this to say:

The Project Leadership is expected to ensure that their Project Plans are consistent with the Roadmap, and that all plans, technical documents and reports are publicly available. To meet this requirement, each Project is required to create a transparently available Project Plan in an EMO-defined file format that meets the following criteria:

1. Enumerates the areas of change in the frameworks and tools for each proposed Release
2. Consistent with and categorized in terms of the themes and priorities of the Roadmap
3. Identifies and accommodates cross-project dependencies
4. Addresses requirements critical to the Ecosystem and/or the Membership at Large
5. Advances the Project in functionality, quality, and performance

The EMO-defined file format, or “standard format” is defined on the wiki. There are numerous examples that you can draw from when creating your own project plan (Mylyn, RAP, IDE4EDU, and Web Tools are just some examples).

For a project plan to be considered “valid”, it will be in the standard format, be valid XML, conform to the schema, and contain future milestones. It’s not enough to have a plan that lists themes: to be valid, a project needs to have actual future dates so that committers, contributors, and adopters can adjust their own plans accordingly. The standard format schema has a specific place for dates (./release_milestones/milestone). It’s not enough to list dates in the HTML markup. One further requirement is that the plan has to be correctly captured in the project metadata on the Developer Portal; that is the “projectplanurl” field needs to point to the XML document (e.g. “http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_3_6.xml”).

At present, we have 17 projects with valid project plans. We have 40 projects with plans in the standard format but with missing milestones. A whopping 65 projects have plans that cannot be found (i.e. the plan URL is not specified in the project metadata), or are in an invalid format (be sure to check that the project plan document is valid XML). The good news is that the number of projects with valid project plans has been increasing steadily over the past few days. I’m encouraged by the willingness of project leaders to try and get this right.

In the past we’ve been a little negligent with respect to plans during reviews. Moving forward, the EMO pledges to help projects make sure that their plans are in place and valid as part of all release, graduation, move, promotion, continuation, or restructuring reviews. In fact, basically any kind of review, short of a creation or termination review needs to include a valid plan.

That said, it’s probably a good idea to have your project plan up-to-date at all times. If you need some help whipping your project plan into shape, let me know. Project leaders: you know how to find me.

Keep in mind that the numbers will overlap a bit. Any users who upgrade mid-month would be included in the count for two versions.

You’ll probably notice that the release documentation for Visual Editor 1.4 is a little brief. After some reflection, I decided that the documentation was sufficient given that this release really isn’t introducing any new functionality, but rather can be regarded as a bug-fix release (as described in section 6.4 of the Eclipse Development Process) and so a release review isn’t strictly required (see exception #3). We decided to go ahead with the review since the version number doesn’t conform to the usual bug fix numbering convention of incrementing only the “service” segment for bug fix releases.

Next up is Sequoyah. “What is Sequoyah?”, I hear you ask. Well, Sequoyah will be the new name of what has previously been known as the Tools for mobile Linux Project. The move/rename review documentation describes how the TmL project contains components that are useful on many mobile platforms, not just Linux and so a rename is in order. It further discusses how some code wound up being put into the Mobile Tools for Java project due to timing issues and that’s it’s now time to move that code to its more appropriate home. There are some other code contributions occurring as part of this move and so I encourage you to take a closer look at the document.

You can find out more about the review schedule on the “What’s new with Eclipse Projects” page. These reviews are an opportunity for the community to ask questions at key points in a project’s life-cycle. I invite everyone to find out more about these reviews and participate. Even better, get involved with the projects before the reviews so that you can participate more actively!