Replacing Bugzilla with Tuleap

Bugzilla has served the Eclipse Community well for many years, easily scaling to serve the needs of over 500 open source projects, servicing a community of thousands of software developers generating half of a million issue reports over close to two decades (I’m taking some liberties with that last one: it’s been about 17 years). When I say “easily”, I mean that our world-class IT team has made it look easy.

While generally robust, Bugzilla isn’t sexy, and it’s missing some valuable features. I’m also a little concerned that the team responsible for maintaining Bugzilla doesn’t seem to have the resources necessary to move Bugzilla forward (though, I’ll admit that I have only limited insight).

I’ve been investigating Tuleap, which is billed as “software development and project management tool”, as a potential successor to Bugzilla. Any effort to make Tuleap a first-class service for Eclipse projects will include the deprecation and eventual retirement of Bugzilla. Much like our migration from CVS to Git, I expect that project teams will start slowly adopting the new technology. Much like that other migration, the pace will likely pick up quickly as project teams see the benefits being reaped by the earlier adopters. This is how it will have to be: with project teams migrating themselves completely off Bugzilla and into the new system.

The criteria for picking a Bugzilla successor is pretty straightforward. Any new issue tracking software we adopt must:

  1. be able to import our existing issue (bug) data;
  2. be open source;
  3. have a strong community behind it; and
  4. provide equivalent functionality to what Bugzilla provides today.

Tuleap can import existing Bugzilla data directly, so that’s a huge win. We’ve discussed potential for synchronising data across systems, but that’s a big and expensive challenge that I’d really like to avoid. Once a team decides to move to Tuleap, the data will be moved and they’ll be off. This is an important consideration for project teams that might be considering participating in the ongoing proof of concept: we do have a means of moving your existing data from Bugzilla to Tuleap, but currently don’t have a means of making the return trip should we decide to move in a different direction.

Requiring that the replacement be open source is, I think, obvious. All of our public-facing systems are open source today and this will continue into the future.  Tuleap is 100% open source.

Having a strong community is important and ties into the open source requirement. Replacing Bugzilla is going to be a massive undertaking and we need to have confidence that the replacement that we choose has some staying power. Tuleap appears to have some large enterprise organizations adopting the technology, which is encouraging. We’ll expect to contribute to the open source project, but we need to be part of a community that plans to contribute and continue to evolve the product.

I think that it would be a mistake to look for a feature-to-feature replacement for Bugzilla. If we’re going to make this change, then we need to do some dreaming. Having said that, with my experimentation so far, I believe that Tuleap provides most of the fundamental functionality that we require.

A small number of our projects have started to independently evaluate the potential to use Tuleap. I’m certainly not an expert, but I’ve engaged with both the Tuleap project itself and several the Eclipse projects testing Tuleap via Tuleap as a user, so I’m starting to get a pretty good feel for it. So far, my experience has shown that it’s a pretty awesome bit of software and the projects that are currently using it seem to be moving along nicely.

Tuleap is more than an issue tracker. What I think sells a lot of project teams on Tuleap is the ability to engage in a full Scrum or Kanban process, but Tuleap provides all sorts of other services, including a wiki, document management, Git hosting, Gerrit integration, and more. It is relatively easy for a project team to create additional Git repositories from directly within the Tuleap interface. There is a notion of a project landing page that likely overlaps (at least a little) with the PMI; it may be worth investigating integration options (I’m not particularly keen on project teams being required to manage multiple landing pages on different services).

Tuleap provides fine-grained permissions which would make it relatively easy to, for example, give a project lead the ability to grant access to non-committer triagers (I believe that our various policies permit this sort of thing).

It is possible to add custom fields into a project team’s bucket to capture information that may be specific to the project. My understanding, however, is that the user experience for this sort of administrative task is not as refined as the user-facing interface. Customisation can be templated, which may make it possible to share some set of common customisations. But customisation introduces a troubling problem: since the source and target may have different customisation, moving issues from one team’s bucket to another team’s bucket is not currently supported: moving issues must be easy (especially considering the number of bugs that are incorrectly opened against JDT). Tuleap also does not currently provide an easy means of marking duplicates. According to the project team, these important features just haven’t been implemented yet. I’ve opened an artifact to track the need requirement to easily move issues.

Unfortunately, I believe that the abilities to move an issue from one project team to another, and to quickly and easily mark duplicates are critical to our adoption and so are show stoppers for the moment.

I have been trying to think a bit outside of the box. One of the bigger drivers for the need to be able to move issues is that the JDT team is the target for any and every issue that comes up in any variant of an Eclipse IDE that includes Java development tools. Maybe we can use adoption of a new issue tracking system as an opportunity to help our users find the right place to report issues without having to navigate our project structure. That’s going to require a lot of thought and energy from the community as a whole.

I think that Tuleap has a lot of potential, but we’re not quite ready for widespread adoption by Eclipse projects. I’ve managed to identify two show stoppers, but they’re point-in-time problems that will be addressed. I believe that we’re setting up a BoF at EclipseCon Europe 2016; if you’re using Tuleap now, or are interested in being a part of the decision making process for widespread adoption, please attend that session (and, of course, please do feel free to connect with me one-on-one at the conference). Please also to interact with the projects currently using Tuleap and let me know if your project is interested in participating in the experiment.

Finally, please join the discussion on Bug 497333.

EclipseCon Europe 2016

Posted in Community | 7 Comments

Java 9 module-info Files in the Eclipse IDE

Note that this post is not intended to be a status update; it’s just a quick update based on some experimenting that I’ve been doing with the beta code.

It’s been a while, but I’m back to experimenting in Java 9 support in the Eclipse IDE.

For testing purposes, I downloaded the most recent Oxygen (4.7) integration build (I20160914-0800) from the Eclipse Project downloads the latest  Java 9 JRE build (135).

I configured the Eclipse IDE to run on the Java 9 JVM. This still requires a minor change in the eclipse.ini file: to launch successfully, you must add to the vmargs section (I expect this to be resolved before Java 9 support is officially released; see Bug 493761 for more information). I used and used the Install new software… dialog to pull in updates from the BETA_JAVA9 SDK builds repository (see the Java9 Eclipsepedia page for more information).

I created a very simple Java application with a file. Content assist is available for this file.


Note that there is an error indicated on the import of java.awt.Frame. This error exists because the module info file does not provide visibility to that class (AWT is not included with java.base).

If we change that requires statement, the visibility issue is resolved and the compiler is happy. Well, mostly happy. Apparently not using declared variables gets you a stern warning (this is, of course, configurable).


The Eclipse Project is planning to ship support as part of an Eclipse Neon update release that coincides with the official release date of Java 9. I’ll be talking a bit about this during my JavaOne talk and demonstrating this (and more Java topics) at the Eclipse Foundation’s booth.

Conference: JavaOne
Session Type: Conference Session
Session ID: CON6469
Session Title: Developing Java Applications with Eclipse Neon
Room: Hilton—Continental Ballroom 6
Date and Time: 09/19/16, 11:00:00 AM – 12:00:00 PM

The call for papers for Devoxx US is open. Devoxx is a community conference from developers for developers. Submit your proposal now.

Posted in Java, Neon, Screenshots | Leave a comment

Eclipse Project Branding and Trademarks

As part of the project creation process, the Eclipse Foundation assumes ownership of the project’s name.  As a legal entity, the Eclipse Foundation owns all Eclipse project and corresponding product trademarks on behalf of the the Eclipse community. This prevents companies and others from misusing or misrepresenting their products as being the projects.

For a trademark assertion to hold any value, an organisation must take steps to protect that trademark. That means that care must be taken in the manner with which the name is used by the owners themselves and the community. Generally, the steps taken to protect a trademark are concerned with avoiding confusion in the community and ecosystem. The Eclipse Foundation’s publishes guidelines for the use of our logos and trademarks. This is, of course, not unique to the Eclipse Foundation: many organisations, including open source organisations, publish guidelines describing how their trademarks may be used.

A big part of the value of a project moving to the Eclipse Foundation is the Eclipse name. The value of the Eclipse name, of course, comes from the value provided by the projects. The relationship is circular: one props up the other. With this in mind, I’ve added a new Branding section to the Eclipse Project Handbook which describes the sorts of things that project teams should do to prop up their own individual brand along with the Eclipse brand (I’ll publish updates the LocationTech and PolarSys Project Handbooks shortly).

I don’t think that there is anything particularly controversial in this document. For many of our projects, there is very little (if any) additional work that needs to be done. For most projects, the full extent of the work that needs to be done will be to consistently prefix their project name with “Eclipse”. The document also attempts to provide some guidance for community websites that aren’t hosted using resources approved by the Eclipse Foundation (to conform to our Freedom of Action rule of engagement, official project websites must be hosted on EF-supported infrastructure).

Starting in July 2016, the EMO will—as part of all release and graduation reviews—review the project’s use of trademarks and help project teams conform to the guidelines.

Posted in Eclipse 101, EDP, Project Management | 3 Comments

Longest Serving Eclipse Neon Contributors

I’ve been running various queries against our Git index database. I decided to see who are our longest standing contributors. I had to draw the line somewhere, so I set the cut off at 4,000 days between their first commit and their last.

Here is the list of our longest service contributors:

Silenio Quarti, Grant Gayed, Carolyn MacLeod, Dani Megert, Steve Northover, Olivier Thomann, John Arthorne, Dejan Glozic, Doug Schaefer, Mikhail Khodjaiants, Pascal Rapicault, Markus Keller, Mike Wilson, Thomas Watson, Chuck Bridgham, Nitin Dahyabhai, Stefan Xenos, Bogdan Gheorghe, Ed Merks, Susan McCourt, Kenn Hussey, Nick Boldt, DJ Houghton, David Williams, Gorkem Ercan, Scott Lewis, Peter Nehrer, Yulin Wang, Wei Yan, Greg Watson, Keith Chong, Rick Lu, Atsuhiko Yamanaka

Note that this is restricted to only those developers who are (or have been) committers on projects that are participating in the Eclipse Neon release. This, and all of the other caveats that I mentioned yesterday apply.

The list is ordered by the number of days between the date of the first commit and the last. Counting this way, Silenio Quarti is our longest serving contributor (beating Grant Gayed by just one day). There are a few people who have earlier commits than Silenio, but nobody has stuck with it longer.

Posted in Neon | Leave a comment

Eclipse Contributors Since the Beginning of Time

In my last post, I made reference to all the people named Dave that have contributed to Eclipse over the years. I thought that I’d share a little more information about the query behind that.

We maintain a database that indexes all of the commits in all of our Git repositories. This includes the repositories that are on Eclipse Foundation servers and those that are hosted on GitHub. The index includes repositories from Eclipse, LocationTech, and PolarSys projects.

The database records that 2,344 software developers have contributed at least one commit to at least one open source project that is included in the Eclipse Neon release since the beginning of time.

This includes projects that are listed on the release page as well as any subprojects that release with parents that are listed. The Web Tools project, for example, is a single entry on the Eclipse Neon project list, but actually represents ten separate project teams.

The database does not record commits against SVN. Those projects that once used SVN but migrated to Git are included, but the solitary project that remains in SVN, Subversive, is not included in the the number of contributors.

According to the database, the very first commit happened on May 2/2001. I know that there was work done before that, but that’s the first commit that we record. This almost certain masks some of the original contributors.

Way back in the beginning of time, all of our open source projects used CVS which has an important limitation: CVS (and SVN for that matter) only records the identity of the committer, not the author. Author information is tracked elsewhere and I haven’t sorted out a way for the query to take this tracking into consideration, so many non-committer contributors from the CVS era are not represented.

It’s also possible that there is some duplication. We have pretty complete data on changing email addresses, so I have the ability to multiple email addresses, as well as committer IDs and other identifiers from the the CVS days into actual committer names, so I’m absolutely confident that the number is in the right ballpark.

So maybe let’s just say ~2,300 people have got us to where we are today.

FWIW, there are 16 contributors named Mike, 27 named Michael, 10 others with variations of Michael (e.g. Mickael and Mikael), and one Mik. I’m trying really hard to sort out a “drop the Mic” pun, but nothing’s coming to the surface. A little help?

Posted in Neon | 1 Comment

These Are the Daves I Know

Over the years, many people have contributed to Eclipse projects, including some thirty-nine software developers (39) named Dave or David. This list includes everybody who has ever made a least one contribution to one of the many projects that have opted to participate in the Neon Simultaneous Release since the beginning of time as recorded in our Git commit logs.

It’s important to note that prior to our adoption of Git, we didn’t record contributor names in commit records. So some Dave contributors from the early days may not be present in this list. Also, there are probably a Dave or two in the single SVN repository that we still maintain for the Subversive project.

So… without further adieu, here are the Daves I know (some of them are David, but most of them are Dave): David North, Davy Landman, Dave Lerner, David Akehurst, David Berger, David Meng, David Slater, David Nemeth, Dave D, David E. Narváez, David King, David Ostrovsky, David Pletcher, David Kaspar, David Sciamma, David Salinas, Dave Locke, David Dubrow, Dave Stevenson, David Soto Setzke, David Servat, David Lauzon, David Daoust, David Pursehouse, David Kelsey, David Wootton, David Borowitz, David Michonneau, David Springgay, Dave Orme, Dawid Pakula, David Dykstal, David Inglis, David Audel, David Green, David Carver, David Steinberg, David McKnight, and David Williams.

Thank you, Daves, for your contributions!

Bonus points if you can identify the Dave that I’ve known since my university days…

For those of you who don’t get the title reference, let me introduce you to some early 1990s Canadian humour…

If you’re keeping score, there’s only one Gunnar.

Posted in Uncategorized | 1 Comment

Eclipse Platform on Java 9 b118

I’d taken a little break from testing Eclipse Platform on Java 9 Jigsaw builds. A few nights ago, I pulled down the latest builds of both and gave them a spin.

I pulled down build 118 of the 64 bit Linux version of the Java 9 JDK. The last time I did this, the Jigsaw builds were separate, but they’ve since replaced the Java 9 builds, so when you download Java 9 you now get Jigsaw. It’s currently delivered as a .tar.gz file, so I extracted it into a directory on my system.

I then turned my attention to the Eclipse Installer which has a handy feature that hunts down JREs installed on your system and lets you pick the one that you want to use. It also has a handy feature that lets you manually add JREs to the list. The installer includes some logic to help the user avoid making a poor choice, and changes in the way that the JRE reports its version means that the installer doesn’t recognise this particular version of the JRE as a JRE and won’t let you select it (see Bug 493759). I decided to install the latest Neon M7 build anyway using a Java 8 JRE. I launched my newly-installed configuration.

I added the Java 9 Support (Beta) feature from the Eclipse Marketplace. You can install it yourself by simply dragging and dropping the “Install” button below onto your Neon version of Eclipse Platform:

Drag to your running Eclipse workspace to install Java 9 Support (BETA) for Neon

The last time I tested this, I needed to have Eclipse JDT run on the Java 9 JRE to use the Java 9 support; but now, the Java 9 support seems to work just fine when running the Eclipse JDT on a Java 8 runtime. The JDT team has done some significant work, it seems, since I last looked.

I added the Java 9 JRE to the Installed JREs page in the preferences and was able to create and run a Java 9 application.


The bits that I tested all seem to work as expected; e.g. the Package Explorer lists modules.


I only spent a few minutes poking around before moving on to the next task: I wanted to get the Eclipse Platform itself running on this Java 9 build.

I tweaked the eclipse.ini file to point to the Java 9 JVM, by adding the path to the JVM at the top of the file:


I launched the Eclipse Platform and got as far as selecting the workspace before it died with a message to check the log. I opened Bug 493761. The JDT team engaged within hours. Tom Watson (from the Equinox project team) determined that a change in the boot classpath configuration is the cause and suggested as a workaround to add some additional configuration to the configuration file (after the -vmargs line) to ensure that the necessary modules are available.


For more information, see JEP 261. With that modification, everything works as expected.

The workaround is not optimal. For one, the Eclipse Platform fails to launch with this option when you launch under Java 8. The JDT team is looking for a better solution.

Your help is appreciated. If you have the time, please test this yourself and report any new information that you discover.

Posted in Java, Neon, Screenshots | 3 Comments