RE: [jdt-apt-dev] Re: APT as api and tools.jar

["Tim Wagner" <twagner@xxxxxxx>]

I certainly agree with your point about apt being a portable
analysis/generative API across a variety of compilation containers, and
in fact that was a primary motivation in adding it to Eclipse (versus
designing new, Eclipse-centric APIs).

Only you can evaluate whether an annotation processor versus some other
use of mirror APIs is appropriate to your purposes, but at BEA we do use
them for both method and class annotations, across files within the same
project, and in conjunction with external metadata files in XML and
other representations. There is also a "batch mode" switch that attempts
to completely emulate command line apt behavior (at a potential
performance cost) if that's helpful in your scenarios.
 
-----Original Message-----
From: jdt-apt-dev-bounces@xxxxxxxxxxx
[mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of Geoff Longman
Sent: Tuesday, January 03, 2006 5:44 AM
To: Eclipse JDT Apt developers list.
Subject: Re: [jdt-apt-dev] Re: APT as api and tools.jar

On 1/3/06, Tim Wagner <twagner@xxxxxxx> wrote:
> 1. Is APT going to make it into Eclipse 3.2?
>
> Yep - it is "in" 3.2 in the sense that it's in the code base, but
> currently resides on a branch. The branch will be integrated with the
> head by the February platform milestone date. (I believe that's around
> 2/19.)

Fantastic

>
> 2. tools.jar - how can APT make it into 3.2 if you have to copy
> tools.jar?
>
> First, Sun is BSD licensing the mirror APIs, so it will be possible to
> include a stripped down version of "tools.jar" as part of the Eclipse
> 3.2 image. However, since it is dependent on a 1.5 VM, the APT
> functionality will not be enabled for use unless the VM Eclipse is
> running on is 1.5 or greater. That's also what would happen if we were
> unable to include the jar for any reason - the functionality would be
> gracefully disabled unless the VM was correct and "tools.jar" was
> available. In that (hopefully unlikely) scenario, users would have to
> obtain their own, properly licensed, version of tools.jar in order for
> the functionality to appear.

Cool.

>
> Finally, your use case sounds like a description of a classic
annotation
> processor; what's the problem with approaching it that way?

Tapestry is approaching the use of annotations in a curious way.
Tapestry "Pages" and "Components" are built up from a combination of
xml and annotations and a template. There are *very* complex
algorithms involved with determining what class is related to what xml
and what template. And, they are run in the context of an entire
project and not an individual class. It's my understanding that the
ann processor is invoked when a class with a certain (configurable in
the factory) annotation is encountered. Tapestry does have a
"component" and a "page" annotation. When those annotations are used,
yes, a processor in theory a processor could handle the job. But in
practice I don't think it's doable as the entire context of the page
is not available.

Also, those component and page annotations are *optional*. There are
many other annotations that Tapestry uses too, mostty method
annotations. At runtime Tapestry takes a component class and uses
reflection to get all the class and method annotations  that are
present in the type's hierachy. The class declaration itself may have
no annotations at all and if that is the case, correct me if I'm
wrong, the processor will never see it.


I've been looking at the mirror api and it looks to me as an excellent
way to access the source code in an Eclipse independant way. If I were
to port my tools to say, IDEA, I would only have to reimplement what
you have done in the IDEA "way". Right now I use the standard JDT dom
and ast and of course that is not platform independant while the
mirror apis are.


Geoff
>
> -----Original Message-----
> From: jdt-apt-dev-bounces@xxxxxxxxxxx
> [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of Geoff Longman
> Sent: Monday, January 02, 2006 8:12 AM
> To: jdt-apt-dev@xxxxxxxxxxx
> Subject: [jdt-apt-dev] Re: APT as api and tools.jar
>
> Oops sent before I was done my use case:
>
>  1. Load xml spec
>  2. Locate class (usually a java file but not always)
>  3. Find all tapestry annotations on the class (incl inherited)
>  for each annotation:
>    do something
>  4. get all methods (not just locally declared methods)
>     for each method:
>        get method annotations
>           for each annotation:
>              do something.
>
> Geoff
>
>
> On 1/2/06, Geoff Longman <glongman@xxxxxxxxx> wrote:
> > Hey,
> >
> > Just stumbled over APT and I must say it is very cool. Have some
> questions...
> >
> > 1. Is APT going to make it into Eclipse 3.2?
> > 2. tools.jar - how can APT make it into 3.2 if you have to copy
> tools.jar?
> >
> > Lastly, any thoughts yet on the API story for APT? I'm building a
> > project that has a builder, and that builder needs to access stuff
> > like annotations at the source level. My story does not fit into
that
> > of an annotation processor but having access to the mirror api
> > implementation provided by APT would really help me out.
> >
> > A bit of a use case - the tooling is for the Tapestry
> > (http://jakarta.apache.org/tapestry)
> >
>
> >
> >
> >
> >
> > --
> > The Spindle guy.           http://spindle.sf.net
> > Get help with Spindle:
> > http://lists.sourceforge.net/mailman/listinfo/spindle-user
> > Announcement Feed:
> > http://www.jroller.com/rss/glongman?catname=/Announcements
> > Feature Updates:            http://spindle.sf.net/updates
> >
>
>
> --
> The Spindle guy.           http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Announcement Feed:
> http://www.jroller.com/rss/glongman?catname=/Announcements
> Feature Updates:            http://spindle.sf.net/updates
> _______________________________________________
> jdt-apt-dev mailing list
> jdt-apt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jdt-apt-dev
> _______________________________________________
> jdt-apt-dev mailing list
> jdt-apt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jdt-apt-dev
>


--
The Spindle guy.           http://spindle.sf.net
Get help with Spindle:   
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:    
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates:            http://spindle.sf.net/updates
_______________________________________________
jdt-apt-dev mailing list
jdt-apt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-apt-dev