Two weeks gone, two more to come

I’ve been absent from this blog for quite a long time, so I’m letting you know a bit of what’s been happening lately.

First, I have been working on q4e during most of my free time, which includes not only coding, but also helping the growing community on the mailing lists.

Add to that that I’ve been finally assigned a client and I’m halfway through the initial getting-to-know-the-stuff fase. Is an interesting client since I landed in the security area of the product they build (which is doubly interesting as my previous work was more on the “product user” side and now I’ll get to see both sides of it). The product itself is also interesting, as it is the process (is a much bigger company than what I was used to). I might speak a little about it in a later post.

Finally, I accepted to teach an introductory course to JEE, focused on getting new people joining the company up-to-speed. Most of the attendants come straight from university, but I also have some colleagues with C/C++ and even Cobol background, so it is being a really interesting and motivating experience.

So it is no wonder I haven’t written a line here lately :D .

Good news is that the JEE course is halfway done (only two more weeks are left) and I will get my evenings back for whatever I choose to do. Like writing in this blog, contributing to q4e and, once q4e is ready, updating Candy for AppFuse.

Testing internal classes in Eclipse

When writing a plug-in for eclipse, one can select which parts are public and visible for every plug-in (that will be the exposed API for extenders) or internal.

This is clearly a good idea. Consumers of you’re plug-in see only what they need, so they are saved from looking at the gory details.

However, you might like to test your internal API, which is usually done from a different plug-in… which won’t have access to the internal API that needs to be tested.

Is there a solution? Of course!

Expossing internal classes to a single plugin

What needs to be done is to export  the internal packages as if they where API, but change their visibility so only the test plug-in can see the classes.

Done! You can have a tested plug-in which a clear separation of public API and internal logic.

Candy for AppFuse will be under extreme refactoring

This is the last piece of news that I wanted to share with you since long, long ago.

It has been a long time since I released a version of Candy for AppFuse. There are several reasons for that, the most important of them being my lack of time. Another reason is that I wanted to contribute all that I could to the core maven support in eclipse, something that has not progressed as fast as I wanted.

As you might already know if you’re a reader of this blog, a new solution for maven2 support in Eclipse (called q4e) is on the works with releases coming to light every few weeks.

Being a committer in q4e means that I can more easily push Candy features in the core of maven support. To name a few:

  • Configure a maven project after creating it or importing it into Eclipse.
  • Configure arbitrary repositories.
  • Discover available archetypes.
  • Integrate maven projects with existing eclipse plugins.

Most of this is already present on Q or being actively worked on by the team. The project is being pushed forward by DevZuz, which brings (to me at least) some extra confidence, since there is people that can dedicate their work hours to the project (and not just the little spare time I’m bringing). And there is very talented people there, who also play an important role in the maven community, so bugs are squashed no matter where they come from :) .

So, what does this mean for Candy?

It will be separated in pieces and built again. Core functionality would be in q4e, with extension points that will allow to properly support AppFuse.

Since q4e targets Eclipse 3.3 and Java 5, this means Candy will be Eclipse 3.3 only, with Java 5 or greater. There will be WTP 2.0 integration as soon as possible (but I will decline any invitation to set a deadline… this is my free time ;) ). Probably DTP and SpringIDE will be next.

I’ll maintain the existing version of Candy as long as possible, so if you find bugs, let me know. Improvements will have to wait until Candy is working on top of q4e.

Even when this is pretty much set, I would like to hear existing Candy users’ opinions. Leave me a comment.