Community
Participate
Working Groups
I have a project using JAX-WS, and I use an ant task to run the annotation processor against my web service source and generate the server side artifacts. I have the ant task configured to produce both the source code and compiled classes. For example, assume I have the following package structure: com.example.echo Echo.java BeanObject.java com.example.echo.jaxws <Generated Source> Lets assume that the Echo class has a web method that returns a BeanObject. When I add a web method to Echo and run my ant task to run the annotation processor, code is generated and placed into com.example.echo.jaxws. That generated code will import BeanObject. The code is also compiled into the build directory, and the BeanObject class will also get recompiled by the annotation processor. At this point, if I refresh the entire project, I have no problems and will see any new classes generated by the annotation processor. But if I refresh any of the subdirectories, I get errors like "com.example.echo.BeanObj cannot be resolved to a type" coming from the generated classes. This occurs regardless of whether any new classes have been generated. It seems that simply the recompilation through the annotation processor is enough the cause a problem. If I compare the compiled class files (one compiled by eclipse, the other by apt) the files are the same size but diff reports them as different. Once the project is in this state, a refresh of the entire project will not fix it, the only way to correct it is to clean and rebuild the project. This did not occur in earlier versions, I tested with 3.2M4 and 3.1.2.
Moving to JDT/APT
It sounds like this may be a bug in JDT rather than APT. Are you using the APT support in Eclipse, or simply executing apt.exe (part of the JDK) from within ant?
Yes, I think it would apply to the JDT. I'm not using the annotation processor within Eclipse, I'm running apt through an ant build outside of Eclipse, and then I get this problem with I refresh the package where code has been generated/compiled by apt.
Moving back to JDT/Core. What do you mean by "If I compare the compiled class files (one compiled by eclipse, the other by apt) the files are the same size but diff reports them as different." ? How are they different ?
I just mean that the class files are not identical when compiled by apt vs. Eclipse. This may not be relevant, I'm not sure. APT generates the source code and also compiles the source. If I do a clean build through Eclipse, then Eclipse will be compiling that source. If I save the compiled class file, and then run my apt ant task, the file will be recompiled. If I compare the saved Eclipse compiled file with the apt compiled file using diff, they aren't the same. The modification timestamps would also not be the same, obviously. This may just have to do with the differences in the compilers, where both would generate valid bytecode they might not be identical. The file sizes are the same however. As far as the specific differences in the files, I'm not very knowledgeable about the structure of the classfile/bytecode. I noticed that certain structures such as the InnerClass table were in different positions, but I don't know what the consequences of that would be, if any. I thought this might have something to do with Eclipse not recognizing those classes when I perform the refresh, but this is just speculation. I can provide a test case if it would make things easier, I just didn't want to attach here because the file would be rather large, there are a lot of library jars that would need to be included for the JAXWS framework.
Yes, please. I would be interested by a reproducable test case. Thanks.
I cannot reproduce with 3.2M6. Do you still have the issue on your side?
I just tested with 3.2M6 and I still have the same problem. If anything is unclear about the steps to reproduce let me know and I'll clarify. Also, I don't know that this would make any difference, but I'm testing on MacOS. I can try over on a linux machine and see if the problem occurs there.
yes, please. Try on Linux. I don't have an easy access to a Mac. However I do have a linux box. I tried the steps as described in the attachment you sent me and I could not reproduce.
I can reproduce on Linux with 3.2M6 as well. Just to be clear here are the steps that reproduce the problem for me: 1. Get the project built correctly in eclipse (clean and rebuild). Make sure Build Automatically is enabled. 2. Run the build-server-java ant task (I tried in eclipse or from the command line and got the same results) 3. Right click on com.example.jaxws.echo.impl.jaxws and select refresh. 4. You should get build errors.
I had to change the build.xml slightly to get the ant task to work correctly on linux: Here is what I used for the jaxws.classpath: <path id="jaxws.classpath"> <fileset dir="${lib}"> <include name="*.jar"/> </fileset> <fileset dir="${java.home}/lib" includes="tools.jar"/> </path>
When I run it under Linux, I get: build-server-java: [apt] warning: Annotation types without processors: [javax.annotation.Resource] [apt] 1 warning [apt] warning: Annotation types without processors: [javax.xml.bind.annotation.XmlRootElement, javax.xml.bind.annotation.XmlAccessorType, javax.xml.bind.annotation.XmlType, javax.xml.bind.annotation.XmlElement] [apt] 1 warning Not sure this is expected. And once I do the refresh, no errors appear. Could you please give me the error that your got? I used N20060410-0010. Your problem looks like bug 135729. This was supposed to be fixed in M6. It is weird that I cannot reproduce, but you can do it. Would you have specific settings in your workspace? Would it be possible that instead of providing simply the project, you provide a workspace that contains only the project and in which you can reproduce this issue ? Thanks.
I'm almost certain after reading about bug 135729 that they are the same issue. As I read it, that issue has been reproduced and is not fixed in 3.2M6, but scheduled for a release candidate. If you need anything more from me at this time, let me know. Thank you.
*** This bug has been marked as a duplicate of 135729 ***
Changing OS from Mac OS to Mac OS X as per bug 185991
