Community
Participate
Working Groups
The Pollinate project makes use of APT, Sun's Annotation Processing Tool. (This is forced on us by Apache Beehive, which Pollinate is based on.) Thus, Pollinate must know the location of tools.jar, which is where APT resides. This adds to the configuration burden for Pollinate users. It would be wonderful if an APT workalike based on JDT existed. This is no small task, and we don't know who else would use such a thing, although if it existed we suspect other open source projects would tend to adopt it, much like Tomcat 1.5 allows the use of JDT. But we wanted to get a request for this on the table.
Forgot to include the following links in the description: Pollinate project - http://www.eclipse.org/pollinate Beehive project - http://incubator.apache.org/projects/beehive.html
And the following link as well: APT - http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html
Annotations are new in Java 1.5 and provide very agile platform for language enhancements. APT tool plays quite important role in this direction. I will cite the Kyle Marvin from Bea’s Beehive project (full post is here : http://nagoya.apache.org/eyebrowse/ReadMsg?listName=beehive- user@incubator.apache.org&msgNo=103 ) about key functionality of APT tool needed for Beehive: - A model for how specific annotations are linked to specific processors that perform annotation validation. JSR-175 only provides syntactic validation... but often annotations have semantic meaning in a particular usage context, and this needs to be validated as well. The APT model is not a 'language' model, where all annotations in a file are expected to be understood by a single processor. This enables use cases like pageflows that contain controls, and allows the pageflow processor to deal with the pageflow annotations and the control processor to deal with the control ones. This offers a great deal of richness and flexibility w/out having to create dependencies between processors where it is unnecessary. - A model for how annotations and the language entities they decorate are exposed to the processor. - A model for how annotation errors, warnings, and info can be surfaced by a processor, whether by command line compilation or in the context of another tool (like an IDE). - A model for how annotations can also generate new artefacts, both textual (like descriptors) and types (java source files) that themselves feed back into annotation processing and compilation. I would add that these needs would be equally applicable almost to any tool that will target extensive JSR175 annotations support. Alex.
I vote for annotations, too, since I am developing a domain-specific tool that is entirely based on annotation driven development. I guess there will be loads of such approaches in the next future...
I've also noticed that there isn't a good way to get at the annotations on class files, short of using IClassFileReader to parse it yourself.
APT support is aiming at leveraging these into JDT.
I'll resolve this bug once we have the APT project in HEAD for 3.2. Our current plan is to do so by M5. In the meantime, there is a beta available that works with Eclipse 3.1.1. Documentation can be found at: http://www.eclipse.org/jdt/apt/index.html
As of Eclipse 3.2M5a, APT is included in Eclipse.
