What are you doing with Eclipse right now?

I recently attended a conference session on the topic of getting user feedback. One of the key takeaways for me was that people lie about how they use software. It’s not that they’re trying to be misleading, it’s more that it’s easy to misrepresent yourself out of context. The speaker suggested that you need to interrupt your users and find out what they’re doing at the moment. And you need to do this in regular intervals.

With such a large, diverse, and distributed community–combined with no actual budget–that’s going to be hard to do in any traditional sense.

So I tried a quick experiment on Twitter this morning, asking folks to stop what they’re doing and tell me which views they have on top in their currently-running Eclipse.

I’ve received six responses so far; seven if I count my own (with an audience this engaged, I’m thinking that it might be time to get verified).

  1. Package Explorer, History, and Console
  2. Package Explorer, and Git Staging
  3. Package Explorer, and Search
  4. Package Explorer, History, and Task List
  5. Package Explorer, Task List, Console, and Outline
  6. Package Explorer, Outline, and Console
  7. Package Explorer, Task List, and History

Clearly (and as expected), the Package Explorer get top billing. The Mylyn Task List shows up a lot which is encouraging. That almost half of the responds include the History view is a bit of a surprise (at least to me).

There’s not enough information here to make any real conclusions, but I think the method shows some promise. Let’s see what my next question brings…

Nothing so far…

Posted in Community | 1 Comment

Some “So Far” Stats for Eclipse Luna

I’m working out some of the queries that I’m going run to gather some stats for the Eclipse Luna release on June 25/2014. I’m starting with the Git repositories.

The Git query is relatively simple, taking all commits that have occurred since the Kepler release on all branches into consideration. So the numbers I’m getting do include commits that are not necessarily intended for Luna (e.g. it includes Kepler service release commits).

Here’s what I have so far:

Number of projects: 106

The Luna projects page only lists 71 projects. Many of these projects include subprojects with their release (the Eclipse project includes Platform, JDT, PDE, and others for example). The actual total is 117 projects and subprojects. Of those projects, only 106 actually have code (the Eclipse top-level project, for example, doesn’t have any of its own Git repositories; all contributions from the Eclipse project come from subprojects).

Confusing? Sure.

Number of Git repositories: 188

Many projects have more than one Git repository. There’s a total of 188 Git repositories contribution commits to Luna.

Number of commits: 39,391

This number speaks for itself. For perspective, that’s an average of 108 commits/day.

Number of authors: 687

This is the only fuzzy number in this list. It’s actually the number of distinct author email addresses (as specified in the author field in each Git commit). Some authors may use multiple email addresses, so the actual number of authors is probably smaller than this; but probably not much smaller.

Number of committers: 339

Of those authors email addresses, 339 of them map to committers. For completeness, this is the number of committers authoring commits to their own projects. It does not include contributions to projects by committers on other projects. So, of the 687-339=348 remaining contributors, some of them are committers on other Eclipse projects.

Lines added: 54,760,022
Lines removed: 44,302,716

I’m not sure how valuable either of these numbers is in isolation. Combined, it looks like we have net new 10,457,306 lines of code.

I’m pretty confident in the query behind these numbers, but they’re not “official” (whatever that means). I’ll likely refine the query over the next few weeks. And, of course, these numbers a current as of today. I’ll publish some more up-to-date numbers when the final release candidate is ready for download.

If you have any questions, refinements, or want to see some different numbers, let me know.

Posted in Community | Leave a comment

More names for Eclipse

I regularly receive requests for quotes from purchasing agents for Eclipse software. In almost every case, they’re looking for an Eclipse-based IDE, but don’t quite know what to call it.

Today’s gems are:

  • Eclipse CDT Juno
  • Eclipse Eclipse 352
  • Eclipse Eclipse JSEE Juno
  • Eclipse software Version: Indigo Release
  • Eclipse Java EE IDE for Web Developers

Based on the quantities requested for each of the above, we can count a couple of hundred new users to the Eclipse family.

I find it curious that resellers and purchasing agents can take the time to hunt through our website to find my email address, but apparently don’t bother to look for the names of actual software available from our site. They are presumably responding to a request to obtain software from development managers who also don’t really know what they’re asking for or understand the nature of open source software.

In most cases, I only get to connect with the purchasing agent with no direct connection to the people who end up using the software. I reply with a friendly note explaining the nature of open source software, tell them about the Eclipse Software User Agreement, and give them a link to the downloads. I can only hope that the information is passed on.

Posted in Other | Leave a comment

Screen Capture: Data Tools

Here’s a quick video of the Eclipse Data Tools in action.

From an “SQL Scrapbook” page, you can quickly run and see the result of SQL statements.

Configuration:

Posted in Eclipse 101 | Leave a comment

Automatically-Generated Bug Lists for Releases

Last week we added a new feature to the Eclipse Project Management Infrastructure: we automatically generate a bug list for each release.

The bug list is generated by matching the “target milestones” from Bugzilla to the name of the release record. So, a release named “3.5″ will automatically match bugs with a target milestone of “3.5″. But, since it’s not always that neat and tidy, we decided to make the matches a little fuzzier: a release named “3.5″, “3.5.0″, or “3.5 (Luna)” will–for example–match target milestones named “3.5″ ,”3.5M1″, “3.5 M2″, “3.5.0M3″, etc., but will not match “3.5.1″ or “3.5.2″ (these are considered separate releases).

For help on creating/modifying target milestones, consult the Eclipsepedia wiki.

The current implementation groups bugs by Bugzilla product and component; this seems to work well for releases for most projects (e.g. The Sapphire project’s 8 release). For releases by projects that include subprojects, the subprojects are included in the bug list (assuming that they have similarly-named target milestones). For some releases (e.g. The Eclipse project’s 4.4 release), the bug lists can be quite large, so we may have to noodle a bit on how to make these lists more manageable (the collapsible sections help, I think).

The bug list is displayed on the “Issues” tab (“bugs” just doesn’t seem right, and I’ve never liked the use of the term “ticket” in this context).

The issues page for the Code Recommenders 2.10 release.

The issues page for the Code Recommenders 2.10 release.

If you notice anything anomalous, please open a bug against “Community/Project Management & Portal”.

Posted in Community, Project Management | Leave a comment

Welcome Richard

I’m very happy to introduce the Eclipse Foundation’s newest staff member, Richard Burcher.

Richard will be helping me with “project stuff”. If you take a quick look at Richard’s blog or Twitter feed, you’ll notice that he’s got a an affinity for location/geo-sorts of things in particular and open source software in general (along with an apparent disdain for capital letters). As part of that, Richard has a bunch of experience working with and growing communities. I intend to fully exploit that experience.

We’ve already begun Richard’s immersion into all things Eclipse. It’s been a fascinating and valuable experience for me to explain how things work around here. Assembling materials for the Eclipse Committer Bootcamp, helped me illuminate potential areas for improvement in our process. Working with Richard over the last few days has had an even bigger effect. I’m excited that we’ve already identified a potential ways that we can improve and streamline our implementation of the Eclipse Development Process, while honoring its fundamental underlying principles.

I’m excited by the potential for us to do more to help our open source projects evangelize and court their communities.

More on this later. But for now, please join me in warmly welcoming Richard aboard.

Posted in Announcements | Leave a comment

Add Java 8 support to Eclipse Kepler

Want to add Java 8 support to Kepler?

Java 8 has not yet landed in our standard download packages. But you can add it to your existing Eclipse Kepler package. I’ve got three different Eclipse installations running Java 8:

  • A brand new Kepler SR2 installation of the Eclipse IDE for Java Developers;
  • A slightly used Kepler SR1 installation of the Eclipse for RCP/RAP Developers (with lots of other features already added); and
  • A nightly build (dated March 24/2014) of Eclipse 4.4 SDK.

The JDT team recommends that you start from Kepler SR2, the second and final service release for Kepler (but using the exact same steps, I’ve installed it into Kepler SR1 and SR2 packages). There are some detailed instructions for adding Java 8 support by installing a feature patch in the Eclipsepedia wiki.

The short version is this:

  • From Kepler SR2, use the “Help > Install New Software…” menu option to open the “Available Software” dialog;
  • Enter http://download.eclipse.org/eclipse/updates/4.3-P-builds/ into the "Work with" field (highlighted below);
  • Put a checkbox next to "Eclipse Java 8 Support (for Kepler SR2)" (highlighted below);
  • Click "Next", click "Next", read and accept the license, and click "Finish"
  • Watch the pretty progress bar move relatively quickly across the bottom of the window; and
  • Restart Eclipse when prompted.
Select "Help > Install New Software..." to open the Available Software dialog.

Select "Help > Install New Software..." to open the Available Software dialog.

Voila! Support for Java 8 is installed.

If you've already got the Java 8 JDK installed and the corresponding JRE is the default on your system, you're done.

If you're not quite ready to make the leap to a Java 8 JRE, there's still hope (my system is still configured with Java 7 as the default).

  • Install the Java 8 JDK;
  • Open the Eclipse preferences, and navigate to "Java > Installed JREs";
  • Java Runtime Environment Preferences

    Java Runtime Environment Preferences

  • Click "Add...";
  • Select "Standard VM", click "Next";
  • Enter the path to the Java 8 JRE (note that this varies depending on platform, and how you obtain and install the bits);
  • Java 8 JRE Definition

    Java 8 JRE Definition

  • Click "Finish".

Before closing the preferences window, you can set your workspace preference to use the newly-installed Java 8 JRE. Or, if you're just planning to experiment with Java 8 for a while, you can configure this on a project-by-project basis.

Specify that your project will use a JavaSE-1.8 JRE.

In the Create a Java Project dialog, specify that your project will use a JavaSE-1.8 JRE.

It's probably better to do this on the project as this will become a project setting that will follow the project into your version control system.

Next step... learn how wrong my initial impressions of Java 8 were (hint: it's far better).

The lamda support is so choice. If you have the means, I highly recommend picking one up.

The lambda is so choice. If you have the means, I highly recommend picking one up.

Posted in Eclipse 101, Eclipse 4, Java | 13 Comments