Netbeans growing stronger

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!

Query strings in RESTFul web services

I said before that I don’t like query strings in RESTFul URIs. You cannot cache the results in the web server and in many cases they lead to a poor design of your URIs.

However, there are cases where query strings are useful and make sense. In the project I’m working right now, we have an asynchronous queue which several server instances consume periodically. This queue has events that must be processed, and each event belongs to a given user. Each user may have several events in the queue.

We have this queue of events that must be processed and we register them in another list when they are successfully processed. When an event is processed, he goes to the “processed” list if everything goes right or he stays in the queue if something gone wrong. In the queue we register how many times we tried to process each event.

In my team we have an application that helps us manage our infrastructure. This application does many things that we previously needed to ask to the operations team or DB team. Something very desirable is to be able to check how the queue is going without needing to check server logs or the database. So we’re adding some features in the management application to help us check the queue.

Ok, now let’s talk about the RESTful services. We’ve implemented some services that access the queue. One the of services allows us to check how many events are still in the queue with at least N tries. For example, how many events are pending with at least 1 try?

What’s the Resource here? In my opinion the resource is “Pending event”. Considering this, I would access this resource doing GET /event/pending. Ok, but doing GET /event/pending would probably give us the whole list of pending events. I want pending events with at least 1 try. How can we do that? We could do a GET /event/pending/1, and it would work. However, this URI is bad, very bad. If I didn’t know what this service was about, I’d probably say this URI returns the first pending event according to some order. Probably it would be the oldest or newest one.

So how do we form this URI? We could also have a GET /event/pending/tries/1. This would indeed be much better than the first URI, but I don’t like it either. My resource is “Pending event”. Pending events with at least 1 try are still just pending events for me. What I want is just to filter the pending events. So, I ended up using GET /event/pending?t=1. “t” in this query string stands for “tries”. I could also have used GET /event/pending?tries=1. As a matter of fact, I think supporting both is nice. It would be similar to command line options in Unix applications.

Now, let’s say I want to know the pending events of a given user. Looking at the previous URI, You might say GET /event/pending?u=123 or GET /event/pending?user=123. But in this case, I wouldn’t use query strings. The best URI in my opinion is /event/pending/user, and that would lead to GET /event/pending/user/123. What’s the difference here? I consider the “User” as a meaningful thing. It’s another resource. However, “number of tries” for me is just a filter. I don’t need to know anything about a specific try, so it’s just a filter in this case. Another similiar filter would be “Pending events created before today”. We could have another query string parameter to filter events by creation date. Something like GET /event/pending?c=03/04/2008 or GET /event/pending?creation=03/04/2008.

So, I changed my mind a little bit about query strings. They are indeed useful in some cases, such as this example. They are good to filter results. Filter by something that it’s not a resource. To decide our URIs we must always think of what’s really a resource in our application, and what’s just a filter. Such as in the world wide web, URIs identify Resources. After deciding what’s a resource and what’s just a filter, we can design our URIs much better. Meaningful URIs are among the most important things in RESTFul web services.

Atom: one format to rule them all?

Recently I’ve had several conversations regarding the Atom Syndication Format. This format is gaining more and more adopters and several big players in the industry are using it. Just to name the big boys, Google AND Microsoft are using it to implement RESTful APIs. When was the last time you heard Google and Microsoft agreed on something? This should hint that Atom is indeed a nice thing happening in our field.

Web services using the Atom format for data exchange encapsulate information using Atom’s standard elements and also define some extension points where needed. Some very useful elements are present in the specification. There are standard ways of publishing individual entries and collections, pagination support, links between resources, among other things useful for RESTful web services.

Depending on your domain model, the amount of data you would put in Atom extension points varies a lot. Some domains such as Google Apps can produce a RESTful model that uses a lot of Atom’s standard elements without needing to define too much extension points. However, if you use Atom to exchange billing information between ISP applications, you’ll probably have to define a lot of extension points. I’m saying this to show that some domains match much better to Atom structures than others.

While talking to Silvano (a very clever working mate of mine) a couple of weeks ago, he asked me if encapsulating everything inside Atom elements was not the same as encapsulating everything inside SOAP. This is a very very good question.

When you’re choosing a format for you data exchange in web services, it’s very important to analyse what you gain and what you lose by picking any given format.

For example, a good rule of thumb about SOAP services is: “WS-* is just overhead unless you have something meaningful in your SOAP Headers” (quoting Sanjiva Weerawarana at ApacheCon 2007).

Atom was designed in a RESTful manner by a very talented group of professionals. Many applications are making use of it to exchange data, and the adoption is growing fast. Could it be a silver bullet then?

That’s where I shall leave my observations. If you consider my example of billing information, you’ll see that most of the data there doesn’t mesh well with Atom’s standard elements. Thus, we’d need to define a lot of extension points, and wouldn’t make much use of Atom’s resources. Putting billing data inside Atom entries would represent an overhead without giving us much in return. In this case, I’d rather use my own XMLs directly over HTTP.

Am I saying that Google and Microsoft made a bad decision choosing Atom? No, absolutely not! Their decision was very good. Microsoft is using Atom for Windows Live API and Google’s using it for most of their applications. What do these have in common? They all manipulate web content. They have a domain where many things are accessible on the web, with lots of URIs, different media types, pagination, categories, tags, etc. Atom makes a lot of sense with web content.

I don’t think Atom is a Silver Bullet for RESTful web services in general. Of course you can choose to always use it, and benefit from the standards and the avaiable tools. But isn’t this true for SOAP as well?

What I do think is that Atom is very close to a Silver Bullet when you’re dealing with web content. Whenever you’re developing web services, choosing the right format for your data exchange is one of the most important decisions. To know well the avaiable options is very helpful, and certainly the Atom format brings a lot to the table when your domain meshes well with it. As long as you don’t think it’s the best choice for every application, go ahead and use it wisely

Java annotations abuse

I know Java annotations are a very controversial subject, and there are lots of different opinions regarding them.

In a general manner, i like annotations. Annotations placed on classes and methods are nice, they help a lot without much damage. A good example of well used annotations in my opinion is the Java Persistence API. It reduces a lot of the code you’d need to write and doesn’t polute things too much.

However, placing annotations inside method arguments, such as in JSR-311 (first place where i saw it) starts to really mess things up. Here’s an example of the use they propose:

@UriTemplate("widgets")
public class WidgetList {
@HttpMethod
@UriTemplate(”offers”)
WidgetList getDiscounted() {…}

@UriTemplate(”{id}”)
Widget findWidget(@UriParam(”id”) String id) {
return lookupWidget(id);
}
}

The @UriParam is the one that really bothers me here. I’m sure it must serve a good purpose for the JSR, and it probably makes some stuff easier. However, it’s unquestionable that annotating this much starts to polute the code beyond the acceptable limits. In such a short piece of code we saw 5 annotations.

I’m not saying we should go back to XML files. I really prefer annotations over XML when they are used over classes and methods, much like JPA does it. However, as many other things, annotations can be misused, and in this JSR 311 example, i think they misuse them. I just hope this trend doesn’t get stronger, because i think Java would get uglier with this. Just keep the simple annotations please

Google Data API

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source These guys are good!

Atom feeds for enterprise application messaging

In the last months I have studied and worked a lot with web services in general, and more specifically the RESTful ones. I believe we are going through a fast maturation process in this area, and RESTful web services are becoming the preferred choice for many new implementations. Right in the thick of things in this field is the Atom Publishing Protocol. This is the blueprint solution for RESTful web services, and its adoption is growing fast, reaching much broader scope than just blog applications using the Atom Format.The Atom format and AtomPub protocol can both be used for many interesting purposes. This year I’m working on a big refactoring (actually a new implementation) of a widely used Globo.com application. This application (let’s call it Register) is responsible for the creation of new users and provisioning new services to them, among other features.

A nice concept present in the original development is the use of Application Connectors. Through these connectors, other applications get notified of events that happened in the Register application. An example is: when a new subscriber (a paying user) is created, a connector sends the notification to another application in order to create the subscriber’s mailbox in the company’s external mail provider. Another example is: when a user gets provisioned in the blogging service, another connector sends a notification to the blogger application, that does what it needs in order to create the user’s directory and quota on the file server.

Although i like this concept, it currently has some problems. This connector’s invocation is done explicitly by the Register application. The Register application knows that a new subscriber must receive a new mailbox, and it needs to call a given connector to do this. This is my biggest concern with the current implementation. I strongly believe that an application that creates users must not know anything about mailboxes. In the current structure, when a new application ABC must be notified of events in application XYZ, application XYZ must be modified to invoke a new connector. This doesn’t please me at all. Let me explain a solution that pleases me more

To explain my idea, I’ll propose some examples involving Google and its services. As we all know, Google offers several different services, all of which can be accessed using the same Google account. When you register at Google, you receive a mail account. Let’s suppose that Google Register application sends a new entry to an Atom feed every time a new user is created. This way, every user creation is present on the Atom Feed. If an application (for example Google Mail) needs to be notified of the creation of new users, it just needs to subscribe to the Register’s Atom feed.

Let me propose a richer example now. Let’s say Google starts to offer some super cool software development services. If you’re a developer, you can ask them to give you a “development account”. This development account would give you access to a Subversion repository, a Bugzilla project and a MySql database. Each of these would be an independent service offered by them, subject to change at any given time. The activation of “development accounts” could also populate an Atom feed.

This way the Subversion, Bugzilla and MySql services could be subscribers of the feed, doing everything they need when a new development account is activated, in asynchronous manner. The application that activates the development account has no knowledge of any other services. If Google wants to offer new services such as a Maven repository or a Continuous Integration environment, no problem. The new services would just subscribe to the Atom feed and do whatever they need when a new account is activated.

If Google wants to offer a free development account and a non-free account with better features, there could be another Atom feed for the activation of the paying accounts or maybe updates to the same existing feed. The Register application would know only about registrations, and other components could be easily plugged and unplugged from this process, without modifications on the Register application. Ah, and worth mentioning… totally decoupled from any specific platform. I don’t know how to implement any kind of messaging more decoupled than that.

This is much much better than the way our Register application sends notifications currently. And I’ll be pretty happy once we manage to do this, it’ll be so cool!

By the way, these Google’s software development services would be awesome. My friend Bairos kindly provides me Subversion and Trac services, but he doesn’t have Google’s bandwidth Let’s hope Google gets to know about this and starts offering these services. It’d be amazing!

Elixir of productivity boost

Since I returned from my trip to Argentina and Chile, I’ve been pretty busy at work and when I get home at night. I’m writing an article on web services (more on that in February…) and got a small freelance project to do.Sometimes it’s kinda hard to produce well at night after a tiresome day at work, but a long time ago I discovered my powerful elixir of productivity at night For those of you who do not know me personally, although I’m rather eclectic regarding music, I’m a brave heavy metal fan at heart

When I must start high octane mode at 9 PM, I usually start listening to a power metal set, composed mostly by some finnish bands I love. This year, I’ve been listening to Sonata Artica, Nightwish and Stratovarius most of the time. These bands have some very addictive songs, and the high speed drums combined with the talent of their singers (as for Nightwish, I’m refering to the Tarja Turunen epoch) give me my much needed energy.

Tony Kakko, Tarja Turunen and Timo Kotipelto are really great singers and exceptional live performers.Unfortunately, I never had the chance of going to a Sonata Arctica gig, but I went to Nightwish and Stratovarius gigs in the past and it was awesome. I really like to listen to their live performances, and fortunately You Tube offers a very rich collection of everything you want to listen, so I recently created a playlist there.

For those of you who want to make use of my powerful elixir of productivity boost, the playlist can be accessed here. Long live heavy/power metal! Have fun!

Java Server Faces x Wicket: great framework of old paradigm vs new paradigm

Just beginning 2008, I went to a new area, new team at Globo.com. There are several promising projects for this year, and this team switch will make it easier for me to properly evaluate and judge what I consider the 2 leading Java web frameworks nowadays.Like I said here, on my spare time I (try to) develop a lawyer application which uses Apache Wicket as its web framework. One of the projects I’m now working at Globo.com uses Java Server Faces. This should be a great opportunity to finally go deeply on both frameworks and see in which cases each one is better than the other. Based on what i have already studied and used of both, i do have some opinions that may or may not change several months from now.

First, a little background. When i was studying to pass the SCWCD exam, I saw enough of tag libraries to get really sick of them JSTL, Struts 1.x Taglib, Expression Language, etc etc etc. Every new taglib was a new syntax to learn, and the result of using taglibs to implement complex web pages is the famous tag soup. Not being a purist, although I don’t like scriptlets in general, I do think that in some cases they produce much cleaner code than the heavy use of taglibs.

Having said that, let’s start talking about JSF. Being a standard technology backed by Sun, and present on Java EE 5 specifications, you know that you’re gonna find plenty of support by development tools, many examples on the web and an already mature community of users to help you. JSF offers a huge set of components ready to use, and many of them are very pretty and easy to use. In my case, we’re using JBoss Tools + Rich Faces, and the Eclipse plugins avaiable here are just awesome.

Most of the web applications I have worked until now used Struts 1.x, and although Struts is by far the most successful Java web framework til now, developing with JSF is reasonably easier and more pleasant. However, even considering the clear evolution of JSF over Struts 1.x, I still qualify both within the same paradigm. That is, both have a massive dose of non-markup code in their views, and if you’re gonna work with them, you better have your spoon ready to dig into the tag soup Ok, ok, JSF offers very nice components and manages a lot of the work that was left to the developer in the old times, such as managing the application state and offering a beautiful presentation layer without requiring the direct manipulation of javascript. But you’re still going to have your view layer full of taglibs, coding in a special syntax (the custom tags syntax) that will make it tough to track for problems when they happen within the tag soup. You better have a magical spoon to manipulate it

Rather new in the Java web frameworks field is the very innovative Apache Wicket project. Wicket allows Java programmers to focus on what they do best: write Java code. No taglibs, how refreshing! Wicket also uses componentized development, and it isolates the view from your model in the best manner I have seen til now in Java frameworks. It does not seem so intuitive in the beginning, because you code for a web application in a similar way as you would code a Swing application. Specifically the component’s event handling code in Wicket reminds me a lot of the approach used in Swing applications.

Being a new framework that went out of the Apache incubation just several months ago, you can’t expect great tooling support at this point. Drag and drop tools to design screens? Forget about it! Component options similar to JSF ones? You’re not gonna find it either. However, Wicket has a very active community and it’s evolving fast. The second book on Wicket will be avaiable in a few months and the number of users and successful implementations is growing steadily. The set of avaiable components is growing and it’s becoming much easier to find support in their forums.

As I said, I’m far from an expert in both frameworks, and I hope this year I’ll have a long enough exposure to them and probably in a few months I’ll have more valuable opinions. Something I think about is that perhaps knowing Wicket and JSF well can be really useful, because it doesn’t seem like we have a “one size fits all” choice here. Wicket seems great for a company to base its developments and have good and maintainable code that will be easy to build over for several years. JSF certainly can offer that too, but i find it tough to consider taglib code as easy to maintain. However, JSF offers such great components that even a Java developer like me with no talent to create good looking pages is able to generate a very decent user interface.

I’ll confess I have a natural preference for Wicket since the beginning, but I promise I’ll try to evaluate these 2 options without any passion during this year and later this year I’ll post again telling my conclusions (if any)

Mylyn Trac Connector: accessing web task editor on Linux

My friend Bairos provides me a Subversion repository and a Trac server, and I use both for personal projects.In my job, our issue tracker is JIRA, and I’m using it with Mylyn for several months. However, just recently i started using Mylyn with Trac, in a project I’m developing at home. The Trac server I’m using doesn’t have the XmlRpc plugin, so I’m not able to use Mylyn’s rich task editor with this server, and I faced some problems using the web task editor inside Eclipse on Linux.

Every time i tried to open the task editor, i was getting the following error message: “Could not create Browser page: XPCOM error -2147221164″. I’m not going to detail my analysis of this error, but I was able to fix it installing the packages xulrunner and xulrunner-gnome-support (I’m not sure if both are needed, though).

From my google searches, I could see that this error happens with a lot of applications on Linux, so probably several people using the Trac Connector with the web task editor on Linux faced the same problem. I hope this tip can help.

Just for the records, my environment here is: MEPIS Linux 7.0, Eclipse 3.3.1 with WTP, JDK 1.6.0_03 32 bits, Mylyn 2.2 and Trac 0.10.4

Interview with Robert Elves, from Mylyn Project

In this interview, i’ll be talking to Robert Elves, one of the main committers from Mylyn project. Robert is a key piece in both Mylyn and Tasktop developments, and we’ll talk about these projects, Eclipse, software development process and open source software. Let’s begin!

Bruno Pereira: Robert, how did you get involved with the project? Did you have any prior contact with Eclipse plugin development?

Robert Elves: My road to Mylyn started as a grad student in the CHISEL lab at the University of Victoria. I was researching locomotion in information spaces with a focus on helping software developers. During this time I developed a prototype plug-in for Eclipse called NavTracks that used past editor navigation to recommend files related to the current file being edited.

Around this time I met Gail Murphy and Mik Kersten and learned of what was then the Mylar project, now Mylyn. Shortly after graduation I joined them in the Software Practices Lab at the University of British Columbia to work on Mylyn.

BP: Mylyn 1.0 was released independently from other projects. However version 2.0 was part of the huge Eclipse Europa release. Could you describe this experience? How was this process coordinated in order to have multiple projects releasing new versions at the same time and keeping everything compatible?

RE: With the 1.0 release of Mylyn we were already starting to see increasing download stats in the order of tens of thousands a month, and a strong early adopter community forming around the project. Hundreds of bug reports helped us harden the Mylyn to the point where it became easy enough for many Eclipse-based programmers to adopt this new task-focused way of working. Around that same time, the Eclipse Packaging Project contacted us, asking to include Mylyn in the default Eclipse downloads.

We decided that the technology was ready, agreed, and since then Mylyn has been available to all developers downloading Europa. To participate in the Europa release, projects must meet a number of maturity standards. For example, we needed to prove capable of managing an update site, handling the release schedule, and maintaining an API contract. The requirements for the next simultaneous release, Ganymede, are outlined here.

Mik lead the Mylyn project through these ‘must dos’ to Europa. We adopted the discipline required to meet Europa release chain deliverables while working at a frenetic pace to implement performance and usability objectives. Concurrently we managed to do a complete rename of the project from Mylar to Mylyn and review and accept numerous patches contributed by the community. Projects were coordinated with a lot of communication via wiki and the cross projects mailing list. To sum it up it was a great whirlwind experience and we’re looking forward to more excitement with Ganymede!

BP: From time to time I’m amazed at how Eclipse is expanding its reach. I find the Eclipse project to be a fantastic example of how to build software. With its great component model, it provides a very good platform to build on. As Mylyn makes great use of this component model, I’d like to know your opinions on that.

RE: In my opinion, and I’m sure Mik would agree, Equinox and OSGi make it easier for developers to build better software systems. The framework gives us a mechanism for explicitly separating the concerns of the problem domain into flexible contributing plug-ins. You get runtime deployment and lazy loading of your components practically for free! Without this flexibility and plug-ability, Mylyn wouldn’t exist, because we could not plug into the core Eclipse facilities that the Task-Focused Interface needs to extend. Mylyn contributes and uses a number of extension points enabling the focusing of many of the standard views in Eclipse such as the Package Explorer and Synchronize view. I’ve yet to see a tool platform as extensible as Eclipse, and Equinox/OSGI has been an amazing framework to work with.

BP: Mylyn has been growing and seeing increased adoption by Eclipse users. Along with this adoption there have been many bugs and enhancement requests opened and resolved. How do you pick the bugs and decide what’s going to make it into each release?

RE: Since the Europa release, we’ve seen increased activity in the Mylyn community including more bug reports and enhancement requests. Each report is reviewed by a Mylyn committer. It is important to us to respond in a timely manner as each represents a rough edge or new enhancement request. That said there are only four committers so we carefully triage the bug reports with respect to number of votes from the community, severity, and how each bug fits into the overall plan (See Mylyn 3.0 plan here).

BP: Here in Brazil we are seeing more and more companies starting to embrace agile methodologies and practices, with Scrum probably leading the field. I’d like you to describe your development process, and how challenging is it to make it work having a distributed team.

RE: Agile is certainly how I would describe our team although we don’t strictly adhere to any one particular methodology. We do have weekly planning meetings and constantly re-prioritize bugs based on community feedback in a way that is transparent to our user community. Mylyn itself is one of our key tools to successful collaboration. It enables sharing of task context and the incoming notification on bug reports really helps minimize inbox overload while increasing team awareness. We try to keep all design discussion on bug reports (vs. Skype or other IM chat channels) so that design decisions are available for other team members and interested parties to review asynchronously. Our system is certainly not perfect and we are always looking for ways to improve and streamline our process.

BP: Mylyn has been integrated with a lot of issue trackers, is available on a wide set of Eclipse distributions and is constantly being enhanced by user requests and feedback. I recently heard that you guys are working on a new tool called Tasktop, which is related to Mylyn. Could you provide a vision of the future for the Mylyn project, and what Tasktop will bring to users?

RE: Mylyn will continue to evolve as both a tool and focused-ui framework. Tasktop Technologies leads and supports the Mylyn project. We employ a number of the Mylyn committers, and each of our developers regularly contribute patches to Mylyn.

In the 3.0 cycle you can expect to see the same rate of usability, integration, and performance improvements that we have maintained through the Mylyn 2.0 and into the recent 2.2 release. In order to make the many improvements that show up in our New & Noteworthy documents available to the Eclipse community as soon as possible, we provide GAs of Mylyn quarterly. Some key stuff to look out for in the upcoming Mylyn 2.3 and 3.0 is major improvements to the task editor, which is a focal point of interaction for developers using Mylyn, and addition of light-weight workflow integration to reduce developer click path.

The Tasktop product extends the reach of Mylyn beyond the workspace to the operating system (currently Windows only with Mac support 1st quarter 2008). With Tasktop, your time spent in other applications such as Word or Excel is captured as part of the active task. External application windows are managed similarly to how Mylyn can manage editors within Eclipse. Additionally Tasktop synchronizes with Outlook and Google Calendars giving users an overview of their task schedule from their native calendaring applications. But the best part is that Tasktop focuses all of your web browsing activity. I can now browse the web and use web based applications all from within the Eclipse workbench with the same focus that Mylyn brings to my programming activities. Check out the site to get the beta.

BP: Closing thoughts?

RE: It is great to hear of interest in Mylyn from the Brazilian developer community! I encourage your readers to try the tool if they haven’t already. Also, feel free to help evolve Mylyn by submitting bug reports or contributing patches. We are very open to community contribution!