As a developer, one of the things I really want to do with my work day is development. As a member of a development team, I recognize the need to identify tasks, prioritize work, and (sometimes reluctantly) quantify effort, both in pre-work estimates and post-work time accounting. When these tasks are tracked using compatible software, Eclipse has a built-in tool to help leverage those lists and assist in tracking time and work related to completing tasks.

Anyone using Eclipse has undoubtedly run into Mylyn once or twice, probably by accident. There’s a goofy icon on a number of views that looks like three balls, one in front of the other, and if you bonk it the whole view presents different information than it did before. Especially if done by accident, it can be frustrating and difficult to revert; some of us taking the “when in doubt, restart” mindset brought about by one of our common operating system, and restart the IDE to get the view back to what we expect.

That icon is the gateway to a powerful tool that, like so many others, once understood can provide incredible utility. Before digesting a flow of work that includes using that button, here’s a bit about what Mylyn is.

What is Mylyn?

Mylyn is an Eclipse plug-in, usually included by default in a lot of their packages but available for later installation if necessary; it’s certainly in the Java and JavaEE packages (I would guess these are the ones most of us use). It’s got its own documentation and propaganda site hosted at Eclipse (http://www.eclipse.org/mylyn/), so I’ll try to avoid repeating more than is necessary, instead hoping to shine a little light on the process, inviting you to work it into your own project and application lifecycle management.

Mylyn is a “task-focused interface,” which makes it really useful if you embrace and use Eclipse’s tools for task management. When most of us develop software, we tend to think in terms of projects, work-spaces, or even file system structures. Our software is organized into groups that make sense on some level, and those groups are made of smaller groups. Because of this, far too often we think of our software as a project-based product. As we’re assigned tasks to work on, though, those tasks often break those boundaries. More often it breaks it into a subset of our work-space.

Consider a typical client-server application. There’s probably a workspace (or few) with a project for the server software and one for the client software. There may be a separate project containing common classes developed for use on both sides. There may be additional server-side projects, especially if implementing a SAAS-style project. There may even further be additional sub-projects with an intent on layering or isolating specific implementations, perhaps for the purpose of swapping out for specific environments. When we have such a structure of projects in our Eclipse workspace, there’s going to be a set of top-level projects, each with their sources, libraries, and resource folders.

Consider now a typical list of tasks for such a project. Tasks to create a log-in interface, report log-in failures, provide log-in auditing. Tasks to provide lists of data, allow user sorting or filtering of the data, and even adding, editing, and deleting the data. Where these tasks overlap the projects can be difficult to see initially, but as we’ve all done this, we know there are classes and resources added and affected throughout our work-spaces, across source-tree boundaries, and across projects.

Mylyn doesn’t remove any of this, but as we learned by accidentally hitting that button, it does help streamline the views. Further, it helps when we do that inevitable bouncing back and forth between tasks. Let’s jump in and imagine managing a little bit of development with the help of Mylyn.

Task List

The “Task List” view is the central point for finding, creating, and focusing tasks. It’s really fundamental to making Mylyn make sense, and if you’re not integrating task tracking into Eclipse, much of the usefulness of Mylyn is lost. Out of the box, Mylyn has connectors for Bugzilla, Jira, the built-in Eclipse task list and more! Some of them are added to Eclipse by default, some are just available in the list of plug-ins, and some can be added as third-party add-ons.

The easiest way to get started with your task tracking software is to open the “Task Repositories” view in Eclipse, click on the “Add Task Repository” button (or right-click the middle of the view and add it that way), and in the dialog-box that pops-up, click the “Install more connectors” button. For the most part, once you add the connector, providing whatever URIs, paths, credentials, and whatnot that are required, you should find that your “Task List” view is populated with tasks for you to work on.

Really the installation of a repository and task tracking system is outside of the scope of this document, so let’s just start out using the local task list in Eclipse. This is fine for single machine use, but, of course, doesn’t synchronize by default with anything that allows multiple developers to participate. To play along, you can simply add a task using the “Task List” view; click the “New task” button or right-click and select “New task” from the context menu, choose the “Local” repository, and you’ll be rewarded with a new task window. You can add a title and details if you like, but let’s focus for a moment on the Mylyn bits here.

Looking at the task in the source editor area (that’s where they appear), there are only two Mylyn interactions visible for the Local repository. The first is near the title of the task (once saved); the little purple dot will allow you to activate the task. Once activated, Mylyn (by default) will start keeping track of the work done related to this task. Any files opened in the IDE will become part of this collection, which they call a “context.” In more advanced repositories, and when so selected in the preferences, this will also track the time that the task is active, including noting breaks in editing activity, to help with your time tracking. At the bottom of the task editor window are two tabs, named Private and Context. Clicking the Context tab will show the list of affected files (which should be empty when the task is started).

If you activate a task, you should notice a few things happen. If you still have the task open in the editor, it’s purple dot will appear to be on a depressed button to help identify it as the active task. Likewise, there should be a purple dot next to the task in the “Task List” view. Finally, any navigator windows will also have that annoying three-ball button depressed, and all of the projects and source files will have disappeared; more correctly, the navigator windows will show all of the files that exist in the context.

You can activate and deactivate the tasks easily by clicking the purple ball either on the task editor, or more concisely in the “Task List” view. I recommend keeping the “Task List” open (hide it with a “fast view” so it becomes an icon if you want the real estate back) to allow fast switching between tasks. More on that in a second.

Let’s look at filling the context, now that we’ve got a task set up.

Filling the Context

The various navigation views, such as the “Project Explorer,” “Package Manager,” and the raw “Navigator” are strong users of the Mylyn context. (Note for the purposes of this document, I refer to all of them as “navigation” or “navigator” views, allowing you to choose your favorite or one appropriate for the situation in which you find yourself.) You can toggle the context filter on the views without affecting the context tracking help Mylyn provides. This allows you to work as you always have, but still take limited advantage of the Mylyn task-focused interface. Since we’re trying to embrace Mylyn, let’s shift how we work a little bit.

Activate that sample task. If you’re not playing with an existing work-space, create a project to play with (or create one anyway if you want to minimize risk to other projects). I simply created a new Java project, and named it Foo. Eclipse did what it always did and created the project files and folders in my work-space, but since I have a task activated, I didn’t see anything happen. The workspace itself isn’t yet part of the context. I can see my new project by turning off the Mylyn context to verify that it’s there.

My pretend task (and more importantly my empty project) requires me to add a class (or something). If you use the context menus to create classes, you’ll note right away that the folders are missing, so it would seem hard to do so; deactivate the context view, browse to the place you want to make your class and create it. Alternatively, leave the context view activated and use the File menu or context menu on the blank navigator view and get through the “new” menus and dialogs to create a class. Again, I named mine Foo, and in bad form just put it in the root (default package) of my Foo/src folder. Activating the context filter, and the context should contain only my Foo.java, and the navigation viewer tree necessary to display it. If I close the source editor, the file remains in the view, with or without the context turned on. If we return to our task, perhaps by double-clicking it in the “Task List” view, we can check out that once empty context tab, and we should see the same tree view displayed therein.

In a more complete project, we can see that this could be handy in streamlining our navigator views by streamlining the trees to only show the files related to our task. If a file isn’t visible, we can find it using one of the many Eclipse tools such as the “Open Type” (ctrl+shift+T) or “Open Resource” (ctrl+shift+R) dialogs, clicking on a type in our source and hitting F3 or Ctrl+G to jump to its declaration, or even by toggling the context view filter button and navigating to the class and double-clicking to open it in the editor. When the context filter is on, we’ll only see the items opened while the task is active.

Further, the context only contains members visited while the task was active. This helps reduce the context to just the methods and members that were worked on (or reviewed) during the session, helping to further streamline the views. This will aid in removing much of the background noise that occurs as we work on more complete projects, defending our time by filtering out methods in our classes that aren’t related to our task…keeping us focused on the task at hand and the things it affects.

It will happen sometimes that an element isn’t wanted in the context. Perhaps it was opened by mistake, perhaps it was only opened for a quick review but isn’t part of the work being done. Right-clicking a file in the navigator view will allow you to remove it from the context. Be forewarned that doing so will close its editor window. It does not undo any changes made, but does remove it from the context for tracking purposes. Removing higher parts of the navigator trees will prune all the items from the context that are beneath it, too, so you can quickly clean contexts before you’re done working.

Switching active tasks in the Task List switches the context and information in the other views. This is the next best part of Mylyn to the streamlined views.

Switching Tasks

If your project is like most of the projects I work on, it’s seldom the case that you strictly work on only one thing at a time. Well, you probably work on one thing at a time, but switch rapidly back and forth. In many agile disciplines, it’s not uncommon for the start of work on one task to spawn several others. In a “getting things done” mindset, there are two kinds of work; things you can do right now without interrupting what you’re working on, and what you make note of to do later. This can be seen often in software as the simple task of “create log-in” can immediately be seen as needing separate tasks such as generating a web page or other UI, making a message to a service, handling the service request and forming a response, handling the response, and handling errors… Working strictly in a GTD or agile approach, the developer who picked the “create log-in” task should be creating those other tasks as they are recognized.

If you have only the one task discussed so far, create a second task. When done, activate it instead of the first. A few things you may notice should include that the navigator view is again empty, automatically turning on the context filter and removing all of our previous files (not to worry; they’re still not gone). In the “Task List” view, our one active task has the heavy purple ball highlighted, but our previously active task has a dim purple ball. This indicates that the other task has items in its context associated with it. If we reactivate the other task, our editor and navigators should return as we had them when we highlighted the other task. The new task has no dim purple ball as we hadn’t opened anything (if you did as I just described), and its context is empty.

So, this brings to light the bigger usefulness of Mylyn. Switching tasks helps keep the views focused on the items associated with those tasks. As you work on both the client call to the server and the server handling of that call, switching back and forth between those tasks allows maintaining comprehensive lists of software only associated with those tasks. Those lists may overlap, for example in a common classes project used by both our client and server, but the client task would mostly have client code in its context, and the server code would likewise have its code but not the client code in its context.

Further, when using the more advanced task repositories that support it, the time spent on each task will be correctly recorded. Perhaps it takes all day to write the client-server query and response, but the two tasks could be unevenly divided in the day, and this can help track the six hours for one and the two hours for the other separately. Additionally, if you’re interrupted with a meeting, either deactivating the active task or going idle will stop the timer, and the interruption won’t make the task seem disproportionately time-consuming.

Time-tracking is turned off by default, but is easy to add. In the Window menu, select Preferences. Then find Tasks in the list. Near the bottom of the right pane is “Time Tracking.” Turn on the “Track time” check box, and time tracking will start when tasks are activated and the time will be added to task lists that support it. In our simple use of the Local repository, there will be a simple “active time spent” bit at the bottom of the task editor windows.

Task Updates

Note this time is for the entire task, not any specific activity on it, so if you’re looking to track parts of a task more accurately, you need to use a task repository that allows incremental updates such as comments and post comments as bits are done, so you can see the differences in time for each bit. Task repositories like Bugzilla or Jira both support this.

While our simple Local task tracker will keep a list of the files affected, the more advanced trackers do much more than that. For example, using Bugzilla allows uploading the context as a zipped attachment, containing the Java files and resources in the context. This allows gathering files for code reviews or a kind of version control to be directly associated with the task tracking. Some tools that integrate with both task tracking and version control will use Mylyn to help coordinate the context through other means as well.

When completing tasks, the “Task List” view allows filtering them out. Test this by opening one of our simple tasks, clicking the complete button and saving it. It should appear dimmed and crossed-off. Then click the crossed-out check mark button on the tool bar and our dimmed task disappears from the view. Toggle the button and it returns. The task and its context can be recalled at any time, to refresh your memory on why it was created and what work was associated with it.

Conclusion

To take all of this in a wrapped-up day-to-day example, we’ll assume a task tracking system is in place and incorporated in the Eclipse “Task List” and that a project full of source already exists. Done with the previous task, a skim through the task list will help pick the next thing to do. Many heretofore unmentioned features of the task list include ordering by expected due date, and filtering by assigned developer if the tracking tool allows it.

Selecting a task, the developer activates it. Depending on the tracking system, this should include a submission back to the repository so that the task will be noted as in progress and another developer won’t select it. Once active, the IDE should present a clear, streamlined work-space. In accordance with the requirements of the task, the developer opens and creates new classes. Occasionally more work than can be easily done may be noted, so the developer pauses and adds new tasks and subtasks. Perhaps correlating work is found to be necessary and appropriately other tasks are activated and noted as in progress, like the first one.

As work is completed, in part or in whole, the developer marks progress on the active task, submitting comments and contexts, optionally with time updates, to the task repository as well as version control system. Switching tasks switches views, helping focus the work to what is important to that task.

As tasks become complete, they are marked as done in the task repository, with their final context and time updates committed. As the set of tasks diminishes, the developer winds down this set of work. Eventually the last task is marked as complete and all of the code is committed.

A deep breath and sigh of relief, and the developer returns to the task list to find the next thing to do…