That's an exciting time for BEA.

We now have announced we are joining Eclipse with a number of interesting things in the pipe, ranging from AOP with the AspectWerkz/AspectJ effort leading to AspectJ 5, to the IDE part that will shape up BEA WorkShop, and leading positions in the Web Tools Platform, and in the JDT compiler area.

Things were a bit odd when we shipped an AspectWerkz Eclispe plugin some month ago, since everyone out there was thinking that there was a death match between BEA WorkShop and Eclipse... Didn't you thought that way ?

And don't say we have started to sneak in randomly just to catch up. Things are now ranging from the JVM with AOP work going on within JRockit up to the IDE...

Read the news
http://biz.yahoo.com/prnews/050222/sftu152_1.html

Last time I was reading about a project, folks were arguing they had many many tests.

But what is exactly this measurement ? Do we have to count the number of classes that extend JUnit TestCase , or the number of test*(..) methods, or the number of calls to JUnit assert*(..) ?

The current figures for AspectWerkz are pretty much those one:
- 92 extends TestCase
- 544 test*() methods
- 1380 calls to assert*(..)

Off course, what would matter would be the coverage (that has several definitions as well), but still, the number of test in an interesting thing to define.

So how many tests do I have ?

Today Jonas and I shipped Backport175, a back port of the JSR-175, the Java 5 Annotations spec.

This project comes with an Eclipse plugin and an IDEA plugin, so its time to say something about IDEA...

I just like the architecture of the IDEA plugins. There is very few docs on the topic, some very bad javadoc, and some samples around but no books yet etc.
Anyway, you can find some help on the IDEA forums, and guys like the Groovy ones have written plugins as well, so you can find a bunch of code around.

The nice thing in IDEA plugins is that it s just code, a rather clear API, and a bit of IOC (IDEA is using PicoContainer). A plugin as just one XML descriptor.
For an Eclipse plugin, you need a lot of XML, find what are the extension point, and dig in the docs and books, and get familiar with the Eclipse plugin wizardry. The game is very different, while for IDEA, it s just an API that you have to get familiar with.

What is missing the most in IDEA v4 is a good plugin project wizard, but if you have the chance to give a try to IDEA IRIDA, the EAP of the upcoming v5, then you have it, and it's as easy to debug your plugin as it is for a regular app.
The great thing with IDEA is that you can write a very small Ant script to build the plugin. I would not even try to go there for Eclipse (perhaps I am wrong ...).

You can probably learn some in that space by comparing both Backport175 plugins. It will leads you thru
- how to have a menu of your own to add / remove the feature to a given project (nature / actions and menu)
- how to hook in in the build system (builder / compilation listener)
- how to deal with markers

Off course, it is probably not the correct design neither for Eclipse nor for IDEA (I am far from beeing efficient in that plugin area) but it seems to do the job.

IDEA plugin CVS
Eclipse plugin CVS

Thanks to JetBrains to allow free use of IDEA for OSS projects !