Toggle Line Numbers in Eclipse

I’ll admit that I’m dumbfounded by how much people care about whether line numbers are on or off by default in Eclipse. Put the cursor into the gutter area to the left of the editor and right-click to bring up the context menu, select “Toggle Line Numbers” to change the state to match your preference.

Toggle Line Numbers

Most of the standard packages have line numbers turned on by default starting with Luna.

If you’d rather conserve screen space, you can just leave them off and use ctrl+L (cmd+L on the Mac) to jump to a line.

Hit ctrl+L (or cmd+L) to jump to a particular line

Or just use the debugger.

I’d love to hear what you think about everything except whether or not line numbers should be on or off by default (seriously, it’s done: time to move on). I’ll be at Devoxx France in Paris next week. Attend my talk, or visit me at the Eclipse Foundation booth (joined by Obeo and Codenvy).

Posted in Eclipse 101, Java, Mars | Leave a comment

Great Fixes for Mars Winners Part I

A Great Fix is a contribution provides a significant improvement in the Java development experience using Eclipse. Special consideration will be given to performance or stability improvements, and patches that improve the user experience. To qualify, a fix needs to be merged into the project repository by a committer.

For our first round in the Great Fixes for Mars skills competition, we have a total of 29 qualifying fixes, submitted by 9 contributors.

Here are our winners:

Andrey Loskutov

Andrey contributed twelve qualifying fixes (it’s a query, so the results may have changed since I posted this) for the Great Fix competition. Some of these contributions are significant in their own right, but together they represent a staggeringly large contribution including a broad range of performance, stability and user experience improvements. Andrey—who currently holds the #2 spot in terms of contributions made to the project in the last three months—has been invited to join the Platform UI project as a committer.

Mateusz Matela

Mateusz made a huge contribution which basically reimplemented and improved the JDT’s Java code formatter. The contribution includes 240 files changed, 8,422 insertions, 17,295 deletions. This fix improves performance and stability in the formatter, with a significant impact on the Java development community.

John Glassmyer

John contributed patches (core, ui) that fix issues with how imports are organized and sorted. His two commits change 28 files, with 3,007 net new lines of code including comprehensive changes to the JUnit tests, that fix seven separate bugs from JDT Core and UI. Some of these are long time bugs, dating back to 2004.

John, Mateusz, and Andrey all win fancy new Nexus 9 Android tablets graciously donated by Google. We’ll be contacting you shortly to confirm your co-ordinates.

All runners up will receive an Eclipse T-Shirt. All runners up are still in the competition!

The next deadline is April 1st. No fooling.

  • Deadline: April 1/2015; the three top-prize winners will be announced on April 3/2015 (Mars M6)
  • Deadline: May 6/2015; the four top-prize winners will be announced on May 8/2015 (Mars M7)

Fame and glory await!

Posted in Announcements, Community, Java | Tagged , , , , | 3 Comments

Nested/Hierarchical view of projects

From the Eclipse 4.5M5 New and Noteworthy documentation:

The Project Explorer now provides the ability to view the projects in a hierarchical (a.k.a. nested) form. For modular projects, this allows to have your Project Explorer mapping more closely the organization of your modules as they are on the file system. This hierarchical view of projects often makes easier to navigate modular projects.

Hierarchical view of projects can be triggered from the Project Explorer view menu, under the Projects Presentation item.

Hierarchical view of projects can be triggered from the Project Explorer view menu, under the Projects Presentation item

Then it makes the folders that are at the same location as a project replaced by the project, and the projects that are nested under other projects will not be shown as root elements.

This implementation relies on the Common Navigator Framework.

Posted in Java | Leave a comment

Eclipse N!

The Eclipse Planning Council—with help from the community—is trying to sort out the name for our eleventh named simultaneous release in 2016. We had some trouble with the first set of names that we selected, and so we’re into the second round.

The Lynn Lobby has significant momentum.

The “Eclipse Lynn” Lobby has significant momentum.

We started following the alphabet a few years ago, naming our fifth release “Helios“, and now we’re up to the letter N. We’ve been bouncing around some N names on Twitter; I quite like the idea of just going with “N”, and stated as much.

I originally put in the exclamation mark to make it seem more exciting, but then it occurred to me that the exclamation mark has special meaning in Lisp. In a functional programming language like Lisp, you generally avoid changing state, so Lisp functions that make changes are marked with a cautionary exclamation point (spoken as “bang”). When you invoke a bang function, things are going to change:

It seems appropriate. Change is in the air. I’m excited by the prospect of having an actual installer. I’m excited by our vision of the future of the developer’s platform.

With Mars, our June 2015 release, we’re making a subtle shift to put more focus on the user experience. This takes the form of our Every Detail Matters for Mars effort which aims to tackle a handful of “little things” like getting more of the default preferences right in our packages, standardizing naming conventions, providing reasonable and useful package-specific new and noteworthy documentation, improving the story for adding simultaneous release plug-ins into an Eclipse-based IDE, and more. I’m pretty excited about some bits of the “and more” part, but I’ll save that discussion for another day.

Of course, we’re also trying to tackle some pretty big things. We’ve come a long way towards having a proper installer for Eclipse. I’m also optimistic that we’ll be including Gradle support in Eclipse (more on this later).

We need your help and so we’ve started the Great Fixes for Mars skills competition. To enter, all you need to do is take responsibility for a bug, mark it as “greatfix”, and submit a patch. We’ve even provided a list of great suggestions where you can make the biggest impact. There’s prizes. Cool prizes.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

This shift in momentum will build through Mars and into the 2016 release. I’m certain that N-bang will usher in even bigger changes.

But what do I know? I’m just an Old Dude Who Knows Smalltalk (and Lisp).

EclipseCon 2015

Posted in Other | Tagged , , | 4 Comments

A Vision of the Future of the Software Developer’s Platform

How will the developer’s platform change over the next three years? Will you still be using desktop-based development tools? Cloud-based software development options are getting more powerful, but will they completely replace the desktop? For a certain set of developers, cloud-based software development tools will be a natural fit and so we should expect migration to tools like Che. But the desktop will remain viable and vibrant well into the future: for many classes of problem, the desktop is the right solution.

Of course, there will be grey areas. Some problems can be addressed equally well by desktop- and cloud-based solutions. For these sorts of problems, the choice of development tools may be–at least in part–a matter of developer preference. There will be other drivers, of course (the exact nature of which is difficult to speculate). For this grey area, the ability for a software developer to pick and choose the tools that are most appropriate for the job is important. Further, the ability to mix and match development tool choices across a team will be a key factor.

I’ve spent a good part of the last few months working with a group of Eclipse developers to hammer out a vision for the future of the developer’s platform. Here’s what we came up with:

Our vision is to build leading desktop and cloud-based development solutions, but more importantly to offer a seamless development experience across them. Our goal is to ensure that developers will have the ability to build, deploy, and manage their assets using the device, location and platform best suited for the job at hand. Eclipse projects, the community, and ecosystem will all continue to invest in and grow desktop Eclipse. Full-function cloud-based developer tools delivered in the browser will emerge and revolutionize software development.

Continued focus on quality and performance, out-of-the-box experience, Java 9, and first class Maven, Gradle, and JVM Languages support also figure prominently in our vision of a powerful developer’s platform.

To paraphrase:

  • Desktop Eclipse will remain dominant for the foreseeable future;
  • Cloud-based developer environments like Che and Orion will revolutionize software development;
  • Developers will be able to choose the most appropriate tools and environment;
  • Projects can move from desktop to cloud and back;
  • Desktop Eclipse developer tools will gain momentum;
  • The community will continue to invest in desktop Eclipse-based IDEs;
  • Java™ 9 will be supported;
  • Developer environments will have great support for Maven and Gradle;
  • Support for JVM languages will continue to improve; and
  • User experience will become a primary focus

You’ve likely noticed that this is focused pretty extensively on Java development. This is not intended to exclude support for other programming languages, tools, and projects. As the expression goes, “a rising tide lifts all boats”: as we make improvements and shift focus to make Java development better, those improvements will have a cascading effect on everybody else.

My plan for the near future (Mars time-frame) is to get the Che project boot-strapped and latch onto the that last bullet with regard to the desktop IDE: user experience. While user experience is an important consideration for most Eclipse projects, it needs to be a top focus.

This vision of the future isn’t going to just happen. To succeed, we need organizations and individuals to step up and contribute. I’m aware that project teams are stretched pretty thin right now and many of the things on the list will require some big effort to make happen. Our strategy, then, is to start small.

I’m buoyed (in keeping with my sea metaphors) by the overwhelmingly positive response that we got when we turned line numbers on by default in some of the packages. I’ll admit that I don’t quite understand the excitement (it’s such an easy thing to toggle), but for many of our users, this was a very big and important change. The curious thing is that–while the change was preceded by a lengthy and time-consuming discussion–making the actual change was relatively simple.

My take away is that we can have some pretty big wins by doing some relatively small things. With this in mind, I’ve been poking at an informal programme that I’ve been calling “Every Detail Matters” (I borrowed this name from the Gnome community). Every Detail Matters will initially tackle things like names and labels, default settings for preferences, documentation, and the website/download experience (I’ve set up an Every Detail Matters for Mars umbrella bug to capture the issues that I believe make up the success criteria).

We’re also trying to tackle some relatively big things. The “installer problem” is one that I’m hopeful we’ll be able to address with via the Oomph project. I’m also pretty excited by the prospect of having Eclipse release bits available from the Fedora software repository on GA day.

In parallel, we’ve launched a more formal Great Fixes for Mars competition with prizes for winning contributors of fixes that improve the Java development experience.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

I’ll set up a BoF session at EclipseCon to discuss the vision and our strategy for making it real. It’d be great to see you there!


EclipseCon 2015

I wrote about the Platform Vision in the November Eclipse newsletter.

Posted in Community, Java | Tagged , , | 2 Comments

Great Fixes for Mars

We’re launching the “Great Fixes for Mars” programme. As is suggested by the name, we’re looking for great fixes in the form of contributions to Eclipse open source projects. There will be prizes.

EclipseCon 2015

A “Great Fix” is a contribution from a non-committer  that provides a significant improvement in the Java development experience using Eclipse. Ultimately, the committers will decide what constitutes a “Great Fix”, but special consideration will be given to performance or stability improvements, and patches that improve the user experience.

Now this is important: to qualify, a “Great Fix” must be a fix, not a new feature or enhancement. And, we’re particular about the nature of the fix: it must improve the Java development experience. I’ve asked committers from the Java development tools (JDT) project to suggest some bugs that they’re particularly keen to have addressed to seed the discussion. You can, of course, pick other bugs, but the suggested ones are most likely to result in success. We’ll be including other Java development related projects in this as well.

The first 100 bugs on the Eclipse Platform 4.5 Planning Bugs page are a great place to start. The Platform UI project provides a very comprehensive How to Contribute guide to get you started. I recommend that you use the Oomph Eclipse Installer to build and configure your complete development environment (Oomph provides a very intuitive workflow for provisioning an Eclipse-based development environment, complete with cloned Git repositories, that gets you ready to contribute patches via Gerrit in minutes; I’ll post a demonstration video later).

I mean no disrespect to the beginners out there, but this is also important: a “Great Fix” must be fixed by the contributor on their own qualifications. If your starting point is “I want to fix a bug, but don’t know much about the code; please explain how I should start”, then—respectfully—this programme isn’t for you. We’re looking specifically for “Great Fixes” that don’t take a lot of time for the committers to assess and accept (committer effort is part of the judging criteria).

The programme runs in cycles; submissions must be accepted by a project committer before 900h ET on the specified deadline date. We’ll announce the winners at the end of each cycle.

  1. Deadline: March 10/2015; the three top-prize winners will be announced on March 12 at EclipseCon
  2. Deadline: April 1/2015; the three top-prize winners will be announced on April 3 (Mars M6)
  3. Deadline: May 6/2015; the four top-prize winners will be announced on May 8 (Mars M7)

To qualify:

  1. Pick a bug;
  2. Take ownership of a bug (i.e. assign the bug to yourself);
  3. Add the “greatfix” keyword to that bug and use a comment to commit to a completion date; and
  4. Submit a patch via the preferred channel (likely Gerrit).

If a committer thinks that your fix has potential, they’ll +1 your comment in the bug. The +1 means that the committer is interested and will plan to review your contribution when it you submit it. I can’t guarantee that a committer will accept your fix, but if they do and it qualifies, you’ll be in the running for a prize.

Full details are on the web site. I’ll update that page periodically with more “seed” bugs and status.

To answer what I expect is an obvious question: you can qualify for this if you are already a committer on a different Eclipse open source project. In fact, I’d love for you to participate if you’re a committer on another Eclipse open source project.

So, what are the prizes? We have some state-of-the-art Nexus 9 Android tablets compliments of the good people at Google.

Nexus 9 Android Tablets

We’re picking multiple winners in each cycle. Runners up will get an awesome Eclipse t-shirt.

The EclipseCon Hackathon is a good place to get a leg up on the competition!

Posted in Community, Java | Tagged , , , | Leave a comment

Committer Bootcamp at EclipseCon 2015

Are you a new committer or project lead for an Eclipse, LocationTech, or PolarSys project? Are you thinking about proposing a new open source project? In this tutorial, Eclipse Foundation staff members will walk you through the information that you need to know to be an effective open source project committer. The discussion includes an overview of the Eclipse Development Process, the Intellectual Property Due Diligence Process, and the Tools and IT Infrastructure made available to open projects by the Eclipse Foundation.

We’ll be running the Eclipse Committer  Bootcamp at EclipseCon 2015. We’ve scheduled it on Sunday, to avoid conflicting with the fantastic tutorials that are running on Monday. The fun starts at 3 pm (PST); we normally run for about three hours, and–having learned valuable lessons from the past–include plenty of breaks and time for questions. You don’t have to prepare anything; we’ll take care of that.

There will be prizes.

There is some additional information, along with the presentation materials from past offerings of the Bootcamp in the wiki.

If you plan to attend, please send a quick to to emo@eclipse.org to state your intent (so that we can have some sense for the number of committers we should expect).

I’m understand if you can’t make it to the Bootcamp. But you really do need to come to EclipseCon: it’s a fantastic way to connect with the community,  network, and learn.

EclipseCon 2015

Posted in Uncategorized | Leave a comment