Tasktop Blog

We had another fun and informative Eclipse Demo Camp this past Wednesday here in Vancouver with over 50 participants braving the elements to attend. A number of attendees were participating in MOvember. These gentlemen could be easily identified by the presence of a moustache adorning their face (myself included). A number of the speakers were fellow “mo bros” and their donation pages are linked below where you can rate their moustache and make a donation.

What is Eclipse Demo Camp? The Eclipse Foundation sponsors Demo Camp events world wide. The Eclipse Demo Camp is a gathering of local Eclipse enthusiasts, giving individuals the opportunity to present or hear about Eclipse based technology being developed locally.

Vancouver Demo Camp Format. The Vancouver Eclipse Demo Camp has taken the “learn by fire hose” approach: 7 or 8 fast paced 10 min talks delivered by local industry and academics building on Eclipse. This includes a minute to answer a quick question while in parallel the next speaker is plugging in and lining up to deliver their talk. Its fast, its fun, and translates into rapid exposure to really cool technologies in just over an hour. Attendees have commented that this high energy, to the point format offers a nice alternative to events with longer talks.

The Speakers

We enjoyed talks from the following speakers:

Mik Kersten, lead of the Eclipse Mylyn Project and CEO of Tasktop, gave a quick introduction to the Eclipse Ecosystem and why it excels as a platform for innovation.

 
Andrew Eisenberg from SpringSource/VMWare demonstrated Groovy tooling within Eclipse and how easily Grails controllers and model classes can be generated from within the Spring Source Tool Suite. Slides (pdf)

 
Jim DeLaHunt of Jim DeLaHunt & Associates demonstrated how Eclipse can be used to perform runtime debugging of large php applications, something many of us take for granted. He equated life before discovering Eclipse PHP debugging to working with ‘bear skins and stone knives’ to get the job done. Great analogy Jim, I can’t imagine how I’d survive without Eclipse’s debugger.

 
David Green, a committer on the Eclipse Mylyn project, explained the problem of keeping documentation up to date and showed how Mylyn’s WikiText module can be leveraged to build Eclipse documentation crowdsourced from user contributed wiki content (i.e. from EclipsePedia). See David’s blog.  Slides (pdf) Movember Donations

 
Emerson Murphy-Hill from the Software Practices Lab at the University of British Columbia demonstrated a new way to communicate the presence of code smells through a visualizations called “stench blossoms”. These “blossoms” are drawn within the Eclipse editor along the right hand margin and scale in proportion to the severity of the smell. For more information, read the paper and download the tool.

 
Sam Davis from the Software Practices Lab at the University of British Columbia, demonstrated a prototype within Eclipse that dynamically presents the abstractions in your source code more succinctly (so that it feels like you’re using a dynamic language while in fact you’re still using java). You have to see it to believe it. If you would like to try this technology sign up for his user study.

 
Ian Bull from EclipseSource demonstrated the simplicity of customizing and provisioning Eclipse using Yoxos. In addition to custom Eclipse configurations, Ian also pointed out that Yoxos can help developers that need to manage multiple different instances/profiles of Eclipse. Movember Donations

 
David Shepherd from Tasktop closed the speaking protion of the evening off with a few quick best practices when working with Tasktop Pro. David put the call out to all Mylyn and Tasktop users to ping him on his twitter account and share your workflow practices. Slides (pdf), Movember Donations

After the presentations we all enjoyed good food, drinks and conversation. I’m already looking forward to the next Demo Camp! This is the third year Tasktop has organized this Eclipse community event, and each year has been better than the last. Thanks go out to Andrew Eisenberg from the SpringSource crew for helping with this year’s Demo Camp. Also, thanks to whoever provided the runtime debugging of my (paper based) sign up sheet at the event, catching my miss use of the assignment operator:

P.S. My Movember page. Drop me a donation and a comment!

At the Symbian Exchange & Expo conference, I presented a talk called Coordinating contributions: lessons learned growing an OSS community, sharing my lessons learned from the AspectJ and Eclipse Mylyn communities. The Symbian Foundation has adopted the EPL, Bugzilla, and an open development model. What makes the Mylyn project an interesting data point is that with the same infrastructure, it has seen over 800 bug and enhancement reports resolved by patches from a very active contributor community. That’s around 1/7 of our bugs resolved, and falls within the top two Eclipse projects for total contribution count. While Tasktop Technologies has provided the resources for maintaining, supporting and evolving the Mylyn frameworks, we have managed to create a very permeable and successful ecosystem for contributors.

The talk broke the contribution problem up into three pillars: the modular platform that defines the landscape of interesting contributions, the incentive structure needed to drive contributors, and the collaboration tools that support the open development process. While responding questions after the presentation, I was struck by how important the extension install story is to the first two pillars.

Open platforms need easy extension install

If you release a cool tool and nobody can find or install it, does it still make a sound? Not if the sound that you’re after is the roar of broad adoption. One ingredient of an install story is the dependency management technology, which defines the modularity of extensions. In Eclipse, this is a solved problem thanks to OSGi and the Equinox P2 provisioning system.

Another ingredient is incentive structure. The Eclipse Plug-in Central site provided a web portal for listing extensions, but was disconnected from an install story. In contrast, consider the success of the market-driven incentives of Apple’s app store. Or the seamless install process of iPhone apps and Firefox add-ons. Incredible ecosystem growth can result when install technology, modularity mechanisms, and incentive structure line up. While Eclipse provides a great generic install and dependency management mechanism, as the number of Mylyn integrations grew, we realized that a limiting factor of adoption was the discovery of integrations and ease of their installation. In order to continue to support our growth and not overly bias our ecosystem to those extensions that were hosted on Eclipse.org, we needed to streamline Eclipse’s install experience for Mylyn connectors. So we created the Mylyn Connector Discovery tool.

Generalizing Mylyn Connector Discovery

Since the release of Connector Discovery release with Eclipse Galileo, the listing has grown and received consistent praise from users and integrators. We’ve since seen many requests to generalize the mechanism to other install use cases ranging from Eclipse Pulsar SDK installs to the exciting new Eclipse Marketplace effort. The SpringSource Tool Suite is a great example of how the Discovery UI can be leveraged for targeted extension install.

In response to this interest, we have generalized the code and are proposing to move it to the the Equinox P2 project, home of Eclipse install. For details on that proposal see Eclipse bug 295273. What I hope we see in the Eclipse Helios release time frame is the Discovery mechanism as P2 API for special-purpose install workflows, with extensions for Mylyn Connectors, Eclipse Marketplace and more. This Discovery install story is additionally relevant to Eclipse Rich Client Platform (RCP) install scenarios, which often need a simplified and tailored install experience.

While serving on the Eclipse board of directors, a concern I repeatedly raised was the repeated problems that arose from an incomplete install story. The great thing about being part of a meritocratic ecosystem like Eclipse, which rewards participation, is the ability to put code and resources where your mouth is.

The economics of extension listings

A tension that surfaces around shared resources is the Tragedy of the Commons. This gets discussed repeatedly in Eclipse, and can happen in vendor neutral open source ecosystems when organizations attempt to derive value from common frameworks and tools without contributing enough back. As a result, those ecosystems tend to be lead by organizations that understand commercial open source enough to act with enlightened self-interest. But with the continually growing number of Mylyn integrations, we also needed to consider companies with a shorter-term outlook. For example, like other projects, we see the pattern of vendors leveraging our frameworks in ways where they impose a significant support burden on the committers, and not contributing back in terms of patches or resources to help grow those frameworks. While I believe that an open source project like Mylyn should welcome all integrations, an indefinitely increasing support burden is not scalable and can reduce the time available for innovation. We need to avoid the Easter Island effect where everyone builds themselves self-serving heads without prioritizing the long-term health of the ecosystem within which they operate (see Easter Island/Collapse of the Ecosystem).

Discovery style extension listings provide a great opportunity to encourage meritocracy, one of the driving principles of a vendor-neutral development process like Eclipse’s, and help align the interests of a project with those leveraging on it. For good references on meritocracy see Chris Aniszczyk’s recent post. In preparation for last June’s release of the Mylyn Connector Discovery, we worked with our community to create listing criteria that achieve this balance. To paraphrase here, committers can vote you into the listing if you contribute enough to the project to offset the additional burden that you impose on the committers. If you are a vendor and are pulling your weight on the project by growing the frameworks and tools for all integrators to leverage, you can get your own section. If you have a community-oriented open source integration, committers go an extra mile and offer you UI and API reviews in order to help encourage cross-ecosystem collaborations, which can yield a long-term benefit, as evidenced by our collaborations with Mozilla. The listing criteria are open to feedback and input on Eclipse bug 279709.

To date, this meritocratic listing approach has worked extremely well for promoting high-quality extensions and contributions. It has encouraged the growth and adoption of independent efforts such as the Mantis connector, reduced the adoption bias we had of connectors that were hosted on Eclipse.org, and provided a mechanism for promoting the latest round of commercial integrations needed to grow the Mylyn user base.

With a generalized Discovery mechanism in place, I hope that we see a similar trend for other special-purpose Eclipse extensions. For example, the Eclipse Marketplace can use ranking in the Discovery listings for promoting members’ solutions. Projects like Eclipse Pulsar can make their key contributors’ mobile SDKs trivial to install. And the next round of innovative Eclipse projects can use this mechanism to help grow their ecosystem of extensions by promoting meritocracy.

I spent the early years of my career with MacOS and then Linux as my primary OS. When the focus of my work moved to tool building, I decided that I needed to use the OS that was most common in the tools’ target audience. In the Eclipse ecosystem, that’s Windows, which captures more than three quarters of Eclipse IDE downloads.

The great thing about Eclipse is that architecturally, thanks to the amazing SWT framework that IBM created, Eclipse provides a native experience on your OS of choice. But last April, when I moved my primary OS to the Windows 7 RC, I noticed two things. The first was a feeling reminiscent of when I first started using Windows XP early 2001. Windows 7 was slick, responsive, and brought the desktop client to a new level of refinement. The second observation was that Eclipse and Tasktop, which I spend the majority of my time in, looked like dated Windows XP applications.

Today we’re happy to announce that Tasktop is working with Microsoft to help make Eclipse look and feel like an exemplary Windows 7 application. It is great to see Microsoft supporting this effort, since it will impact a broad range of users of the Eclipse IDE, as well users of commercial Eclipse-based IDEs such as the SpringSource Tool Suite IDE, and Eclipse RCP applications such as Tasktop Pro for Windows. Read more about the Microsoft initiative behind this on Vijay Rajagopalan’s post on the Microsoft Interoperability blog.

The majority of Eclipse’s current Windows 7 interoperability comes from the previous efforts of the Eclipse SWT teams and from the backwards compatibility of Windows 7. So you can happily run Eclipse on Windows 7 today. This allows us to focus entirely on leveraging the new features in Windows 7 and on look-and-feel enhancements. Here are a couple of highlights of the initial scope of the effort. Note that all contributions will be made to Eclipse.org under the EPL.

Taskbar Progress (Eclipse bug 293228)

Windows 7 provides a new visual representation of progress on taskbar icons. This feature removes the need to Alt+Tab to an application just to check on the status of a long-running job, such as a download. The plan is to integrate this with Eclipse progress in order to allow some key jobs, such as a full builds and runtime launches, to indicate their status on the taskbar. We already have a working prototype of this functionality, which I’ll show later today when I arrive at Eclipse Summit Europe.

Taskbar Jump Lists (Eclipse bug 293229)

The redesigned Windows 7 taskbar allows applications to expose frequently used features or files. We plan to incorporate this with Eclipse commands and actions that will benefit from quick taskbar based access.

We have some additional enhancements planned, including updating the widget colors and styling to match the Windows 7 look. SWT walks a very careful line in terms of leveraging native widgets, following accessibility guidelines and using desktop themes. Enhancing that experience would not be possible without the technical expertise of the Microsoft Windows and Eclipse SWT teams, whom we have to thank for the high quality Eclipse on Windows experience that we have today. Thanks to this new open source collaboration, what we’ll soon have is the icing on that cake.

If you’re interested in tracking progress, or chiming in with what else you would like to see implemented to streamline the Eclipse experience on Windows 7, refer to Eclipse bug 293226 and its subtasks.

Photo courtesy of seeb’s Photo Stream

In most development circles breaking the build is a serious offense, with good reason. As other programmers check out the broken source code their progress becomes blocked, as they can no longer compile (and thus test) the software. The cost of blocking an entire development team is so large that many shops have resorted to shame tactics, forcing offenders to wear embarrassing hats or shirts. Fortunately, Tasktop can significantly reduce your chances of obtaining a new headpiece by automatically tracking changes related to each task.

Common Problem: Committing Too Much, or Too Little
One of the major causes of build breakage is committing the wrong set of files for a given fix. These types of problems reduce to 1) committing files that are unrelated to the fix and 2) omitting files that are relevant to the fix. Either case can easily cause a broken build as a committed file can reference a new method or field in an uncommitted file. While it might sound easy to track the changed files for a particular task, developers that try to do this manually face several challenges:

1. Tracking individual tasks can exceed working memory – For some tasks developers must change more than a few files. For any task that requires changes to more than seven files the developer must remember a list of files that exceeds many people’s working memory capacity.
2. Multi-tasking requires multi-tracking – Developers work on more than one task in parallel, and thus must track files for each task. If a developer is working on five tasks in parallel, changing as few as three files per task requires remembering 15 files, in addition to the file to task mapping.
3. Tracking changes can span days, or even weeks – A particular development task can often become blocked after the developer has already changed several files. As the developer waits days or even weeks for the task to become unblocked his memory of the changed files will likely start to decay.

Tasktop can help you avoid these problems. It can automatically track the files you change for a given task, freeing up your working memory. Tasktop eliminates the multi-tasking problem as well, tracking changes for each task separately. Finally, it avoids the memory decay problem.

Solution: Automatic Change Set Management

In order to use Tasktop to automatically manage your change sets you only need to activate tasks as you work on them. To activate a task you can click on the icon next to the task in the Task List.

In this example Bug #59, “Cannot read emails from Thunderbird” has been activated, as indicated by the icon and the bold summary in the Task List.

Once you’ve activated a task continue to edit, compile, debug as you normally would. The only changes to your existing workflow are when you finish a task. Once you finish a task open the Synchronize View and toggle the model mode, as shown below:

Once the model is changed to show change sets you’ll notice that all of your outgoing changes have been arranged by task (i.e., a change set has been created for each task). Similarly, all incoming changes are organized by task. Below the same set of changes is presented in the Java Model Mode (background) and in Change Set Mode (foreground). Many people consider it much easier to interpret the changes in Change Set Mode because all of the changed projects and files for a given task are grouped together in that change set. In the Java Model Mode the changes are listed per project, and thus any changes involving more than one project are scattered throughout this list. Additionally, any project that contains changes for several tasks groups the changes together into one change set.

To commit your changes, select the current task, which is bold, and use the context menu to commit the changes. Tasktop automatically fills in your commit comment so that others know which task your changes correspond to, and can navigate from the committed code to the corresponding task.

In the above commit dialog the commit is for the task 5256 and the automatically generated comment includes the task status, task type, task ID, task summary, and, on the next line, the task URL. The format of the automatically generated comment is configurable, and you can change it to match the format that your team prefers (Window -> Preferences -> Task -> Team) by adding the completion date, the assignee, etc. or rearranging the order of the template. For this commit only one file is involved, the AbstractTaskAssociation.java file, which is shown below the commit comment.

Allowing Tasktop to manage your change-sets for you has several advantages. First and foremost, it ensures that you are committing the correct files for a given task. Although it is still possible to break the build* the chances of breaking the build are significantly reduced. Additionally, if you abandon a task prior to committing your changes for any reason, it is easy to revert the changes for that task by selecting “Override and Update” for that change set. Furthermore, all of your commits are automatically commented with a link to the relevant task, so others in the team can more easily interpret your changes. If all team members are using change sets to commit their code it can improve collaboration. For instance, a colleague can commit a fix and ask you to test it. Because the incoming changes are organized by change set you can select the fix of interest and just update that change, isolating the code of interest.

Tasktop’s change set management can reduce your mental burden during programming, allowing you to focus on the important problems at hand by tracking the details for you. If you’d like to get started with automatic change set management, download Tasktop Pro.

* If you work on two tasks in parallel that involve changing the same file it is possible to break the build by committing one of the tasks without committing the other.