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.

On vacation

I’m going on vacation this week, which means no internet, no computers and lots of beach, camping, family, friends and fun.

When I come back, I’ll be trying to finish some open tasks… like reworking the patch in MNGECLIPSE-105 for WTP support in m2eclipse as it is less than perfect now due to an error I introduced when adapting it to work against latest SVN(shame on me).

Also, I have a little surprise hidden… it’s also Eclipse and Maven related… I expect to bring news in a couple of weeks.

As for Candy for AppFuse… no movement there. I’m trying to iron out support for debugging (through WTP) before moving forward. I could add that support to Candy, but I feel it would be far more useful to contribute it to all maven users.

See you in about 10 days .

Candy for AppFuse only for Eclipse Europe?

Because I have upgraded my own eclipse to the 3.3 (Europa) version, I was planning on dropping eclipse 3.2 support.

This is not written in stone, but there are some good reasons for that:

1. Eclipse Europa (in fact, Web Tools Project 2.0) made some interesting changes that will allow greater integration between maven webapps (not only AppFuse) and Eclipse. I’m excited about this and have already contributed a patch to the m2eclipse team (not really my own, based on previous work by Robert Elliot).
2. Lack of resources: I don’t have the resources to maintain compatibility for two different versions. Again this is related to WTP… It is quite different to integrate WTP 1.5 (Eclipse 3.3) and WTP 2.0.
3. Small community. I have no real numbers about how many Candy for AppFuse users exist out there, but according to Ohloh, I’m the only one .
4. At the current development speed, Candy for AppFuse will not be “feature complete” in the near future, so it makes sense to target Eclipse 3.3 for the 1.0 release.

This said, I want to hear your opinions (user or not).

Candy for AppFuse 0.3.1, now runs (even on Windows)

After reading in the Candy for AppFuse forums (thanks to Stetze for reporting it) that there where problems getting Candy to work on windows platforms, I managed to get a windows box to do some testing.

It turned out that some UI related code was working in a different way on OS X and Windows. This caused an exception, making the project wizard unusable on windows.

Now 0.3.1 is in the update site. It should fixes this problem (it works for me, but I would appreciate any reports added to the issue) and also bumps the default version for AppFuse archetypes to the recently released M5 (but remember that you could update the list of available archetypes and versions since 0.3.0).

Windows users, come and have your share of Candy.

Contributing to Open Source

A while back, I’ve read this post on the Flock blog (yes, I’ve been using Flock for a while). In this post Matthew Willis speaks about his experience submitting a patch for Mozilla. He gives some advice about getting your patch accepted and also does some analysis of why people stop sending patches at all.

I must admit that the situation depicted is a little disappointing:

So the moral of this story for me is that if you’re working on a Mozilla-based product, hire an existing Mozilla contributor when possible, and engage the community in dialogue often.

Well, I’m not a Mozilla contributor, but I’m enjoying the chance to send patches to maven2 and friends. So far, it’s been just a pleasure. My first patch to maven2 (probably more will follow as I continue to work in Candy for AppFuse) was reviewed and applied in a really short time, and the request to get it into a new build of m2eclipse is progressing at a good pace.

I must also make a note here for the AppFuse guys, which are very responsive on the mailing list and very fast at reviewing (and fixing) JIRA issues.

All in all, the experience of building an open source project is being very rewarding.