One of the reasons that I am a bit reluctant to use Spring Roo is the fact that it depends on code generation, non-Java code generation at that. Do you address this in your book? What can you tell me to assure me that this is not a liability in adopting Spring Roo.
The following is a FlightService_Roo_ToString.aj AspectJ ITD file:
The above code says that FlightService_Roo_ToString.aj file adds a method named toString to FlightServiceJava class. You can move this toString method into the corresponding FlightService.java source file with just a few clicks in your IDE.
If you look at the above AspectJ ITD file, you can see that it is Java code with slightly different syntax for introducing members to the corresponding Java class. I don't see this can be considered as an impediment in adoption of Spring Roo.
Let's say you have an AspectJ ITD file which contains a single method toString. When you move this method from AspectJ ITD file to the corresponding Java source file, Roo will automatically delete the ITD file because it is no longer required. You don't need to manually delete the .aj files.
Imagine you have a code generation tool that keeps all the information in Java source files. Now, everytime you do something using such a code generator, it'd result in overwriting the Java source file. It also means that you may lose all the customization that you made. In Spring Roo, the code that is managed by Spring Roo is kept in AspectJ ITD files, which you must not modify. This results in clear separation of what code is owned by developer (the code in .java files) and what is owned by Spring Roo (the code in .aj files).
I have added a blog entry that can give you some idea about what typically forms part of .aj files.