Annotation driven programming with Eclipse and ...

| | bookmark | email
The last few days I have been working on defining some more fine-grained transaction demarcations with Spring and AspectWerkz. As the project I am currently working on is still using JDK1.4 I backed to using javadoc based annotations. But the good news is that these are not far away from JDK1.5 annotation thanks to AspectWerkz. So let's see: I firstly have to define a Transactionable interface: As you can see this is not so far away from the corresponding annotation: Yah, you are right, I could write it better: where Propagation and Isolation are defined as Enums. (This annotation is already in the Spring codebase: org.springframework.transaction.annotation.Transactional). But let's get back to our business. After defining the interface I need an annotation.properties file where to declare the short name of the annotation: so now I am able to write in a source: Now, we will have to let AspectWerkz or backport175 weave the annotation into the .class. To do this you have 3 different options:
  • use the Eclipse plugin offered by AspectWerkz or backport175 projects
  • use the AspectWerkz/backport175 org.codehaus.aspectwerkz.annotation.AnnotationC/org.codehaus.backport175.compiler.AnnotationC from the command line
  • use the AspectWerkz/backport175 Ant tasks (org.codehaus.aspectwerkz.annotation.AnnotationCTask, respectively org.codehaus.backport175.compiler.task.AnnotationCTask)
As I wanted not to rely on another plugin I have chosen the 3 solution. Now the question is: is it possible to trigger automatically an Ant task upon project build? And, as you probably already assumed, it is. Right click (or Alt+ENTER) on your project , go to Properties, Builders and define a new builder using an Ant build.xml where you have written the corresponding ant target. Now everytime you'll trigger a build on your project the selected target(s) will be run. After these steps you are done. From now on, all is left to do is to choose correct API offered by either of the above mentioned projects to retrieve a Transactionable instance at runtime (no sources are needed).
Update: a few moments ago I have finished reading the Ramnivas's article where one of the suggested usages is exactly on transactionability demarcation. I am glad I got a confirmation this idea is not stupid [smile/].