Home » Language IDEs » Java Development Tools (JDT) » 3.4 / JAX-WS / Disappearing APT generated files
|3.4 / JAX-WS / Disappearing APT generated files [message #254317]
||Fri, 27 June 2008 21:00
Originally posted by: matt.kolabox.com|
I am new to Eclipse and Java so I apologize if this is a stupid question.
I downloaded Eclipse 3.4 for Windows. I am trying to build a standalone
web service using JAX-WS (I downloaded the 2.1.3 release).
After a while I figured out how to use the project preferences to get the
build tool to use the JAX-WS factories to create the generated web service
It works fine, but almost immediately the files get deleted (by the build
system ?) and not regenerated. If I clear all of the preferences, delete
the .apt_generated folder, it works once and then does the same thing.
I see nothing in the .log file.
What can I do to help diagnose this?
|Re: 3.4 / JAX-WS / Disappearing APT generated files [message #254325 is a reply to message #254322]
||Sat, 28 June 2008 16:51
Originally posted by: matt.kolabox.com|
Walter Harley wrote:
> "Matt Klein" <firstname.lastname@example.org> wrote in message
>> I am new to Eclipse and Java so I apologize if this is a stupid question.
>> I downloaded Eclipse 3.4 for Windows. I am trying to build a standalone
>> web service using JAX-WS (I downloaded the 2.1.3 release).
>> After a while I figured out how to use the project preferences to get the
>> build tool to use the JAX-WS factories to create the generated web service
>> It works fine, but almost immediately the files get deleted (by the build
>> system ?) and not regenerated. If I clear all of the preferences, delete
>> the .apt_generated folder, it works once and then does the same thing.
> Can you say some more about how you have it configured? That is, precisely
> what do you mean by "I figured out how to use the project preferences..."
> You may need to set the processor to "batch mode" in the APT advanced
> factory path options. I seem to recall that the JAX-WS processor makes
> assumptions that are only true for command-line APT and do not work with
> incremental (IDE) compilation.
> -Walter Harley
> JDT APT lead
Changing to batch mode for the processor is a little bit better (the
files are not deleted on a subsequent incremental compilation), but it's
still not correct, because they aren't updated either. Sorry for the
lack of details. Here is the exact configuration:
1) Download 2.1.4 release of JAX-WS.
2) Download 3.4 release of Eclipse w/ Jave EE tools.
3) Create a regular Java project.
4) Create a simple class and expose it as a web service using
@WebService. Create 2 methods and expose them as web methods using
5) Add jaxws-ri/lib to project class path.
6) Open project preferences, enable annotation processing.
7) Open factory path preferences and add jaxws-tools.jar as a plug-in.
After 7), the IDE decides that project settings have changed and a
rebuild is necessary. When this happens I get correctly generated files.
IF batch mode is not set, subsequent builds delete the generated files
and do not re-create them. If batch mode is set, the initial files are
left, but are not updated if I change something. However, in batch mode,
if I do a clean build the files are generated properly.
So, batch mode is closer to working. What is batch mode exactly?
Is there any way to get the build system to always do a clean build for
annotation on each incremental build? Or any options I can pass to the
processor to make incremental work?
If not, batch mode as it is is good enough.
|Re: 3.4 / JAX-WS / Disappearing APT generated files [message #254329 is a reply to message #254325]
||Sun, 29 June 2008 17:30
| Walter Harley
Registered: July 2009
"Matt" <email@example.com> wrote in message |
> So, batch mode is closer to working. What is batch mode exactly?
In general, if you hit F1 while looking at a preference dialog, you'll get a
Help pane. (Little known feature, impossible to discover - I don't know why
these dialogs don't have a Help button.)
From the help on the dialog that lets you set batch mode:
"When this option is selected, the processors and processor factories in
this jar will be run in a mode that enhances compatibility with the Sun(TM)
command-line tool apt. In this mode, processor classes are loaded at the
beginning of a build, executed over the full set of Java types, and then
unloaded, as they would be when running apt at the command line. Processors
run in this mode are only run during a full build, not during incremental
builds. This option is only configurable for jar files; for plugins it is
always set to false. This option only applies to processors using the Java 5
Mirror APIs. It does not affect processors using the Java 6 annotation
This feature was added precisely for processors, like JAX-WS, that were
written to run at the command line and that are ill-behaved in the context
of a long-running application like the IDE. If I recall correctly, the
JAX-WS processor stores data in class statics and assumes that it will get
called only once; it doesn't reset its internal state correctly, and that's
why you're seeing failures after the first time it runs. Without rewriting
the processor there's nothing we can do to fix it, other than this ugly
"batch mode" hack.
> Is there any way to get the build system to always do a clean build for
> annotation on each incremental build?
Well, there's no way to do a clean build "for annotations". It seems like
there should be a way to make every build be a clean build (i.e., disable
incremental builds), but I just spent a little while looking for it and
didn't find one. Unfortunately I think you may be stuck just doing a clean
build periodically. Not very satisfactory, I know :-(
> Or any options I can pass to the processor to make incremental work?
No; I think the processor is just broken, with regard to running in an IDE.
It might be possible to fix it, if Sun has open-sourced the code (when
Eclipse's APT implementation started I don't believe they had, but by now
that may have changed).
Current Time: Sat Aug 29 14:57:50 GMT 2015
Powered by FUDForum
. Page generated in 0.01628 seconds