Community
Participate
Working Groups
I have some plugins collected into a feature and created a build system with curisecontrol for them. Mainly the build process consists 4 steps. - create the build.xml for the feature, which automaticly creates the build.xml files for the plugins - run feature build.xml with target clean - run feature build.xml with target build.update.jar - run feature build.xml with target zip.distribution Now I have a serious problem with the JDTCompileAdapter. On my workstation, the builds runs fine. I got the zip with the feature and all plugins. I can deploy this zip to every Eclipse I want. Now I copied the build system to another workstation. On this workstation the build also runs fine, but the generated jar of one plugin only contains empty package folders and no class files. The log file doesn't say much, the only visible conspicuousness are some missinge massage of the JDTCompilerAdapter. Normaly the JDTCompilerAdapter generates 3 messages for each Java source to compile. [javac] request 1/233 : filename [javac] request 2/233 : filename ... [javac] request 233/233 : filename [javac] process 1/233 : filename [javac] done 1/233 : filename [javac] process 2/233 : filename [javac] done 2/233 : filename ... [javac] process 233/233 : filename [javac] done 233/233 : filename [javac] 233 units compiled [copy] Copying 1 file to temp.folder\jarname.jar.bin [copy] Copied 1 empty directory to temp.folder\jarname.jar.bin [jar] Building jar: temp.folder\jarname.jar [delete] Deleting directory temp.folder\jarname.jar.bin But for this plugin, the output is only: [javac] request 1/233 : filename [javac] request 2/233 : filename ... [javac] request 233/233 : filename [javac] 233 units compiled [copy] Copying 1 file to temp.folder\jarname.jar.bin [copy] Copied 13 empty directory to temp.folder\jarname.jar.bin [jar] Building jar: temp.folder\jarname.jar [delete] Deleting directory temp.folder\jarname.jar.bin The JAR is generated but empty and the overall build result is "BUILD SUCCESSFUL". Any ideas why the JDTCompilerAdapter doesn't continue compiling on this workstation only and no error message is shown? The build environment is the same on both machines. All build steps are launched with a fresh Eclipse installation via "eclipse.exe". There is no JDK in the system path. Eclipse gets a fresh JRE in its subdir "jre\". Command: eclipse -nosplash -data ${build.tempfolder}/buildworkspace -application org.eclipse.ant.core.antRunner -Dinstall.path=${build.sourcefolder} - Dplugin.path=file:${build.sourcefolder}/plugins/,file:${build.tempfolder}/plugin s/ -Dos=${os} -Dws=${ws} -Darch=${arch} -buildfile ${eclipse.ant.buildfile} ${eclipse.ant.target}
Some errors could be pretty fatal to the compilation process, but we should still log the error. Even an internal exception in the compiler is reported as an internal error. Maybe you've found a path where we do not protect correctly., but would need reproduceable steps to assess. Did you try with other JREs on this machine ? Could be some VM badness...
VMs are the same on both machines because the JRE used for running eclispe is copied during the build process from a defined clear case vob. we use this VM in our company wide build process. It is a Sun 1.3.1_02 Win32 JRE. Anyway I tested a 1.4.0 and the same result. I realized that not only one jar is empty. Some plugins generate fine and some plugins have empty jars. I can't veriy because I don't have any error message in the log and I can't reproduce it on other machines. I've also cleaned the environment inside the "cmd" window of the process with no success. I'm not sure but I think it is a classpath problem and after doing some tests I think I'm right. The problem was cause by our build process. I don't know if it is a bug or feature by design of the JDTCompiler/JDTCompilerAdapter but a log message would be nice. Steps to repeat: To repeat the problem, you need to create a customized build situation. I realized that the Eclipse build process used to building Eclipse works directly in the source folders. This is something I (and probably some more developers) don't really like. Thus, the source of our developed plugins is copied to a temp dir into an Eclipse like structure. /temp/build/oursource/ /temp/build/oursource/features /temp/build/oursource/plugins Then a fresh full Eclipse 2.0 zip is unzipped to the following directory. /temp/build/ Thus, we have the following paths: /temp/build/eclipse/ .. fresh full eclipse install /temp/build/oursource/ .. our developed plugins and features /temp/build/oursource/features /temp/build/oursource/plugins Now I invoke the eclipse AntRunner to generate the build.xml files. /temp/build/eclipse/eclipse -nosplash -data /temp/build/buildworkspace - application org.eclipse.ant.core.antRunner -Dinstall.path=/temp/build/oursource/ - Dplugin.path=file:/temp/build/oursource/plugins/,file:/temp/build/eclipse/ - Dos=win32 -Dws=win32 -Darch=x86 -buildfile build_buildscripts.xml buildscript -Delements=feature@our.feature The traget "buildscript" of build_buildscript.xml is really simple. <target name="buildscript"> <eclipse.buildScript elements="${elements}" pluginPath="${plugin.path}" install="${install.path}" /> </target> The PDE "eclipse.buildScript" task generates all build.xml files. Now the problem! /temp/build/oursource/plugins also contains the source of a patched "org.eclipse.ui" plugin. (only 2.0.1 fixes we need and until 2.0.1 is out). Due to some tests I disabled the compiling of the patched eclipse plugins. "eclipse.buildScript" creates a classpath reference to the patched source of the Eclipse plugin because it finds it before the original Eclipse plugin. This behavior is ok. But because of the patched source never gets compiled, the JDTCompiler couldn't compile our plugins because of missing/wrong dirs in the classpath.
So this is not really an issue with the JDTAntAdapter itself, but rather a problem with the ant support inside Eclipse.
I don't think that this is an Ant bug - this is a script bug. If there is a bug in Eclipse Ant support that I do not see, please let me know. Closing for now.
