jdt-apt-dev http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/maillist.html jdt-apt-dev en-us Fri, 03 May 2013 16:03:25 GMT Fri, 03 May 2013 16:03:25 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) jdt-apt-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/maillist.html [jdt-apt-dev] Build Eclipse using Eclipse‏‏ http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00129.html Hello Folks, I'm finding guide to compile/debug Eclipse using Eclipse (or the way Eclipse developers do in real).Hope to get any tip from you. Thanks,Jongwook
Hello Folks,

I'm finding guide to compile/debug Eclipse using Eclipse (or the way Eclipse developers do in real).
Hope to get any tip from you.

Thanks,
Jongwook
]]> Wed, 11 Apr 2012 16:40:21 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00129.html jongwook.kim@xxxxxxx (Jongwook Kim) RE: [jdt-apt-dev] Removal of error markers http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00128.html Hi, James. Thanks for the well-researched question! My recollection of that code is that our intention was to have the behavior as much like JDT markers as possible, but we didn't have a good hook with which to clear them. Also, the person who initia... Hi, James.
 
Thanks for the well-researched question!
 
My recollection of that code is that our intention was to have the behavior as much like JDT markers as possible, but we didn't have a good hook with which to clear them.  Also, the person who initially implemented them may not have been particularly clear or particularly concerned with the details; and we were mostly focused on the situation where autobuild was turned on, thus collapsing steps 5 and 6.  There are currently one or two open bugs on differences between APT and JDT markers.
 
So I'd say it's "just the way things are" but if it changes, it will change in the direction of being more like JDT.
 
Thanks,
  -walter
 

From: jdt-apt-dev-bounces@xxxxxxxxxxx [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Kingdon
Sent: Wednesday, July 22, 2009 8:13 AM
To: jdt-apt-dev@xxxxxxxxxxx
Subject: [jdt-apt-dev] Removal of error markers


Hi,

I have a question about the expected behaviour regarding the moment at which an error marker is removed from the problems view. The question may seem a little pedantic, but I just need to nail down the expectations for a test scenario.

The question pertains to a project where "Build automatically" is turned off, and I'm comparing what I see for an APT generated marker with what happens for a Java compiler based error.

First, with a Java compiler error:

Action, Result

1) Introduce the error into the Java editor, error marker is added to editor, nothing in problems view
2) Save the file, no change
3) Build project, error marker is added to the problems view
4) Remove the error in the Java editor, marker in the editor is greyed out, no change in the problems view
5) save the file, no change,
6) Build the project, greyed out error marker removed from the editor, marker removed from the problems view.

Now, with an APT generated marker:

1) Introduce the error into the Java editor, error marker is added to editor, nothing in problems view
2) Save the file, no change
3) Build project, error marker is added to the problems view
4) Remove the error in the Java editor, marker in the editor is removed, no change in the problems view
5) Save the file, marker is removed from the problems view
6) Build the project, no change

So, adding the markers is the same in both cases (steps 1 through 3), but the APT markers seem to be removed more aggressively, with no greyed out stage in step 4 and the marker removed from the problems view immediately on save in step 5. Are these differences intentional and correct behaviour? Is it "just the way things are" and will be kept that way, or is this something that should and will/might change in the future?

As I said, I don't see this as anything other than a very minor usability oddity, so I'm not asking for a change. I just need to be able to specify the expected behaviour for a test scenario.

Many thanks,
James Kingdon
]]> Wed, 22 Jul 2009 15:34:00 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00128.html eclipse@xxxxxxx (Walter Harley) [jdt-apt-dev] Removal of error markers http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00127.html Hi, I have a question about the expected behaviour regarding the moment at which an error marker is removed from the problems view. The question may seem a little pedantic, but I just need to nail down the expectations for a test scenario. The question pe... Hi,

I have a question about the expected behaviour regarding the moment at which an error marker is removed from the problems view. The question may seem a little pedantic, but I just need to nail down the expectations for a test scenario.

The question pertains to a project where "Build automatically" is turned off, and I'm comparing what I see for an APT generated marker with what happens for a Java compiler based error.

First, with a Java compiler error:

Action, Result

1) Introduce the error into the Java editor, error marker is added to editor, nothing in problems view
2) Save the file, no change
3) Build project, error marker is added to the problems view
4) Remove the error in the Java editor, marker in the editor is greyed out, no change in the problems view
5) save the file, no change,
6) Build the project, greyed out error marker removed from the editor, marker removed from the problems view.

Now, with an APT generated marker:

1) Introduce the error into the Java editor, error marker is added to editor, nothing in problems view
2) Save the file, no change
3) Build project, error marker is added to the problems view
4) Remove the error in the Java editor, marker in the editor is removed, no change in the problems view
5) Save the file, marker is removed from the problems view
6) Build the project, no change

So, adding the markers is the same in both cases (steps 1 through 3), but the APT markers seem to be removed more aggressively, with no greyed out stage in step 4 and the marker removed from the problems view immediately on save in step 5. Are these differences intentional and correct behaviour? Is it "just the way things are" and will be kept that way, or is this something that should and will/might change in the future?

As I said, I don't see this as anything other than a very minor usability oddity, so I'm not asking for a change. I just need to be able to specify the expected behaviour for a test scenario.

Many thanks,
James Kingdon
]]> Wed, 22 Jul 2009 15:13:01 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00127.html jkingdon@xxxxxxx (James Kingdon) RE: [jdt-apt-dev] AnnotationProcessors, Jar files, and quick fixes http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00099.html Hi, J.P. Nice to hear such excitement! Let me encourage you to use the eclipse.tools.jdt newsgroup, rather than the mailing list, for questions on APT. More people pay attention to it, so you'll be more likely to get good answers, and it'll be easier for o... Hi, J.P. Nice to hear such excitement! Let me encourage you to use the eclipse.tools.jdt newsgroup, rather than the mailing list, for questions on APT. More people pay attention to it, so you'll be more likely to get good answers, and it'll be easier for others to search for those answers later. And of course, you are welcome to use Bugzilla (bugs.eclipse.org) to enter enhancement requests and bug reports. Re specifying a directory of compiled classes, the easiest way to get this to work is to package your processors as plug-ins. This is discussed some in the Eclipsecon 2007 tutorial that's linked from the APT web page, at http://www.eclipse.org/jdt/apt/index.html . If you do it this way, then the Eclipse plug-in development environment (PDE) does the dirty work for you. But basically, processor development is like plug-in development, in the sense that you are writing code that is running as part of Eclipse (in this case, as part of the compiler). So you will always end up having two instances of Eclipse, one being the "host instance" containing the processor project, the other being the "target instance" that is running the processor (and that contains the annotated code you are trying to process). It doesn't work to be editing the processor in the same Eclipse instance that is running it, because in effect you'd be trying to edit the compiler that you're compiling with. That becomes a classloader nightmare that we have avoided trying to solve. Regarding the second question, the quick fix classes should be packaged in the same place as your processor; one more reason to package the processor as a plug-in rather than just as a jar. Note that these are not exclusive - you can have a processor that is an Eclipse plug-in but that is still able to be used by javac at the command line, for instance in Ant builds. The tutorial discusses how to do this. I'll be glad to try to go into more detail if needed - again, let me encourage you towards the newsgroups rather than the mailing lists. Thanks, -Walter Harley JDT APT lead > -----Original Message----- > From: jdt-apt-dev-bounces@xxxxxxxxxxx > [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of J.P. Pellet > Sent: Thursday, October 23, 2008 9:47 AM > To: jdt-apt-dev@xxxxxxxxxxx > Subject: [jdt-apt-dev] AnnotationProcessors, Jar files, and > quick fixes > > Hi everyone, > > I have discovered APT in the last few days and first of all, > I have to say how incredibly handy and elegant this is. The > JDT-APT implementation is also pretty impressive, great job, really! > > I have two concerns. First of all, I'd find it nice to be > able to specify also a directory of compiled classes in > addition to jar files and plugins as a place to put > AnnotationProcessors. For now, each time I change my > processor source code, I have to regenerate the jar file > referenced from the project properties page as source for > AnnotationProcessors. If I could just specify the "bin/" > folder of the project containing my processor, I wouldn't > have to do this - or am I missing something? > > Second question (I guess common, put couldn't get it to work) > is about providing a quick fix for my errors. Do I need to > package whatever classes are needed to do this in a plugin > that belongs in my plugins folder, or can these classes be > looked up in some referenced location, similarly to what is > done for AnnotationProcessors? > > Thanks in advance for your answers. Love this API, really, I > haven't been so excited about a language features and what it > allows in years. > > Cheers, > J.-P._______________________________________________ > jdt-apt-dev mailing list > jdt-apt-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/jdt-apt-dev > ]]> Thu, 23 Oct 2008 17:42:11 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00099.html eclipse@xxxxxxx (Walter Harley) [jdt-apt-dev] AnnotationProcessors, Jar files, and quick fixes http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00098.html Hi everyone, I have discovered APT in the last few days and first of all, I have to say how incredibly handy and elegant this is. The JDT-APT implementation is also pretty impressive, great job, really! I have two concerns. First of all, I'd find it nice t... Hi everyone,
I have discovered APT in the last few days and first of all, I have to say how incredibly handy and elegant this is. The JDT-APT implementation is also pretty impressive, great job, really!

I have two concerns. First of all, I'd find it nice to be able to specify also a directory of compiled classes in addition to jar files and plugins as a place to put AnnotationProcessors. For now, each time I change my processor source code, I have to regenerate the jar file referenced from the project properties page as source for AnnotationProcessors. If I could just specify the "bin/" folder of the project containing my processor, I wouldn't have to do this — or am I missing something?

Second question (I guess common, put couldn't get it to work) is about providing a quick fix for my errors. Do I need to package whatever classes are needed to do this in a plugin that belongs in my plugins folder, or can these classes be looked up in some referenced location, similarly to what is done for AnnotationProcessors?

Thanks in advance for your answers. Love this API, really, I haven't been so excited about a language features and what it allows in years.

Cheers,
J.-P.
]]> Thu, 23 Oct 2008 16:46:38 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00098.html jpp-mac@xxxxxxx (J.P. Pellet) RE: [jdt-apt-dev] Intro to APT, debugging APs http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00097.html Hi, Michael. Yeah, that page is pretty deeply out of date - sorry about that; one of the items on the Eclipse 3.5 project plan is to update the web site and add better tutorial material. In the meanwhile, I highly recommend working through the EclipseCon 2... Hi, Michael. Yeah, that page is pretty deeply out of date - sorry about that; one of the items on the Eclipse 3.5 project plan is to update the web site and add better tutorial material. In the meanwhile, I highly recommend working through the EclipseCon 2007 tutorial that is listed on http://www.eclipse.org/jdt/apt/ . Personally, when developing annotation processors, I like to package them in Eclipse plug-ins, which makes debugging easier because you can use the Eclipse plug-in development environment (PDE). That's described in the tutorial mentioned above. But it is also possible to debug a plain-vanilla annotation processor jar in Eclipse. The basic idea is that you have one Eclipse instance (the "host instance") that contains the source code of the processor jar, and perhaps also the source code of the org.eclipse.jdt.apt.core and org.eclipse.jdt.apt.pluggable plug-ins (not necessary, but often helpful); from this Eclipse instance, you then launch another Eclipse instance as your debug target. In the target instance you would have projects containing annotated code, that your processor is going to process; and you add your processor jar to the factory path in that instance. You would put breakpoints on processor code in the host instance, and then in the target instance you build your annotated project code, causing the processor to execute, and you'll hit the breakpoints in the host instance. If you make code changes to the processor code, you'll need to rebuild the processor jar and restart the target instance, for the changes to have an effect. If you package the processor as a plug-in, then PDE will take care of this for you. If you have problems or questions, feel free to post them to the eclipse.tools.jdt newsgroup. Thanks! -Walter Harley JDT APT lead > -----Original Message----- > From: jdt-apt-dev-bounces@xxxxxxxxxxx > [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Reed > Sent: Monday, September 22, 2008 10:18 AM > To: 'jdt-apt-dev@xxxxxxxxxxx' > Subject: [jdt-apt-dev] Intro to APT, debugging APs > > Hi, > I have an already-written Annotation Processor that is > invoked via a makefile (and apt.exe). I'd like to be able to > run it in a debugger. I'm trying to run the tutorial found > here, http://www.eclipse.org/jdt/apt/introToAPT.html , but it > requires org.eclipse.core.runtime.Plugin, which I don't have > & can't find anywhere. Are there other docs that might help > me get started? > > Thanks much, > Mike ]]> Mon, 22 Sep 2008 18:45:18 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00097.html eclipse@xxxxxxx (Walter Harley) [jdt-apt-dev] Intro to APT, debugging APs http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00096.html Hi, I have an already-written Annotation Processor that is invoked via a makefile (and apt.exe). I'd like to be able to run it in a debugger. I'm trying to run the tutorial found here, http://www.eclipse.org/jdt/apt/introToAPT.html , but it requires org.ec... Hi, I have an already-written Annotation Processor that is invoked via a makefile (and apt.exe). I'd like to be able to run it in a debugger. I'm trying to run the tutorial found here, http://www.eclipse.org/jdt/apt/introToAPT.html , but it requires org.eclipse.core.runtime.Plugin, which I don't have & can't find anywhere. Are there other docs that might help me get started? Thanks much, Mike ]]> Mon, 22 Sep 2008 17:17:45 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00096.html mreed@xxxxxxx (Michael Reed) [jdt-apt-dev] Draft JDT APT 3.5 plan available http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00095.html A draft of the development plan for JDT APT in Eclipse 3.5 has been posted at http://www.eclipse.org/jdt/apt/plan.php . The plan is intentionally very limited, reflecting the minimal resources available for this volunteer-staffed project. Any additional he... A draft of the development plan for JDT APT in Eclipse 3.5 has been posted at http://www.eclipse.org/jdt/apt/plan.php . The plan is intentionally very limited, reflecting the minimal resources available for this volunteer-staffed project. Any additional help is always welcome! Please direct comments to the jdt-apt-dev@xxxxxxxxxxx list, or to the eclipse.tools.jdt newsgroup. (Or just send 'em directly to me, eclipse@xxxxxxxxxxxxxxx) Thanks, -Walter Harley JDT APT lead ]]> Fri, 12 Sep 2008 06:18:19 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00095.html eclipse@xxxxxxx (Walter Harley) RE: [jdt-apt-dev] using the same apt plugin in several project http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00094.html Hi, Alessandro. In general, this sort of question should be posted on the eclipse.tools.jdt newsgroup, where it will get much more readership than it could on the mailing list. This mailing list is intended for use by people developing the Eclipse APT i... Hi, Alessandro.  In general, this sort of question should be posted on the eclipse.tools.jdt newsgroup, where it will get much more readership than it could on the mailing list.  This mailing list is intended for use by people developing the Eclipse APT implementation, rather than for users of APT.
 
But I'll answer your question anyway:
 
"Yes and no."  :-)
 
Unfortunately there's no way to change the global factory path; there is also no global setting to turn on annotation processing in all projects.  This was something we considered in the initial APT design, but it led to certain ambiguities that we couldn't find good resolutions for, and at the time we didn't have a compelling use case for it, so it was shelved.  Feel free to enter it as an enhancement request (but don't get your hopes up too high unless you're also willing to contribute the code - there's not much active development happening on APT right now).
 
However, if you wrap your processor in an Eclipse plugin that extends org.eclipse.jdt.apt.annotationProcessorFactories, the extension point attributes will let you set the processor so that by default it is active in all projects.  You still need to enable annotation processing on a project by project basis, but at least the processor will be present in all enabled projects, without needing to edit the factory path.
 
Most processors are only relevant to particular project types - for instance, an EJB processor should only be on the factory path of an EJB project, you wouldn't want it to show up in a J2SE project.  So typically a project creation wizard is written to add the necessary items to the factory path and enable processing, at the time the project is created.
 
When the Eclipse APT implementation was first written, we envisioned the possibility of generic code inspection processors, that a user might want to apply to all of the Java-based projects.  However, no such processors existed at the time, and they are still quite rare, because of certain weaknesses in the APT API that tend to make it insufficient for that task.  Lacking a good use case, when we ran into problems trying to implement global enablement, we decided to leave it unimplemented.
 
Hope that helps,
  -Walter Harley
   JDT APT lead

From: jdt-apt-dev-bounces@xxxxxxxxxxx [mailto:jdt-apt-dev-bounces@xxxxxxxxxxx] On Behalf Of alessandro cinelli
Sent: Monday, June 23, 2008 6:47 AM
To: jdt-apt-dev@xxxxxxxxxxx
Subject: [jdt-apt-dev] using the same apt plugin in several project

Hi all,
I'm developing an apt plugin for my projects.
What i would like to know is if i have to specify the Factory Path in the project properties or if i can export the apt plugin globally in eclipse (as part of it) so i don't have to specifying the Factory Path in every projects.

thanks.


cirpo
]]> Mon, 23 Jun 2008 16:18:30 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00094.html eclipse@xxxxxxx (Walter Harley) [jdt-apt-dev] using the same apt plugin in several project http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00093.html Hi all,I'm developing an apt plugin for my projects.What i would like to know is if i have to specify the Factory Path in the project properties or if i can export the apt plugin globally in eclipse (as part of it) so i don't have to specifying the Factory... I'm developing an apt plugin for my projects.
What i would like to know is if i have to specify the Factory Path in the project properties or if i can export the apt plugin globally in eclipse (as part of it) so i don't have to specifying the Factory Path in every projects.

thanks.


cirpo
]]> Mon, 23 Jun 2008 13:46:37 GMT http://dev.eclipse.org/mhonarc/lists/jdt-apt-dev/msg00093.html alessandro.cinelli@xxxxxxx (alessandro cinelli)