[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-apt-dev] Re: APT as api and tools.jar
|
On 1/3/06, Tim Wagner <twagner@xxxxxxx> wrote:
> 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).
Yep. I wonder, if I were to reach into apt and call
EnvironmentFactory.getEnvironment() would that be usable? (I have yet
to test this I'm still learning about apt and the mirror api).
And what if I passed into EnvironmentFactory.getEnvironment() a java
project that targeted 1.4? Would things degrade nicely (annotation and
generic related methods return null) or would the whole thing be blow
up in my face? I ask because if it's the case that I can go Eclipse
independent using the mirror api on a 1.5 project it would be
disappointing if I had to forgo the nice api for projects targeting
say 1.4.
>
> 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.
I could see my case ending up using both methods: a real processor and
my builder using the mirror api directly. The builder (maybe not a
builder anymore!) feeding the processor the context it needs to play
in the Tapestry sandbox.
Geoff
>
> -----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
> _______________________________________________
> 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
