Community
Participate
Working Groups
While looking into other problems, I've noticed there are many "compile errors" in the log, coming from some "obsolete" SWT code. For example, [javac] 1. ERROR in /opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.swt.win32.wce_ppc.arm/temp.folder/ws/win32/swt.jar.bin/org/eclipse/swt/SWT.java (at line 1) [javac] /******************************************************************************* [javac] ^ [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files I used to check specifically for "ERROR in" messages when I first started building on build.eclipse.org, and there were none, so not sure what's changed ... SWT? Or some releng code. These seem to be in both N builds where I first noticed it. But, when I looked at log from earlier I-build today, it was there too ... so ... not sure what the issue is ... but ... Something is obviously wrong, but not sure it does any "harm" ... I'm assuming what ever it is trying to compile is subsequently ignored, since we don't distribute anything for wce_ppc.arm.
Created attachment 214653 [details] full output log showing compile errors
Bogdan ... any chance you've changed anything in SWT repos that might cause this? My guess is there's just some old releng code ... maybe one of those "master features" ... that's trying to do something with obsolete platforms that it should not be doing, and this "accidentally" causes it to "pull in" some Java code and then the compiler is often set up to "compile any java files you can find" :/ But, as far as I know, this doesn't cause any problems in our deliverables.
to cross reference, this bug may be related to bug 378191.
This is strange - with the nature and number of these errors, we would expect the SWT standalone downloads to completely fail. Yet the WinCE standalone download is present, with all classes there. We can try to reproduce the build steps locally here to see if we get the same errors (if not then I suspect some configuration problem).
Here's one theory that might fit ... but, hard to tell without more info. I think _maybe_ the standalone swt build/packaging happens first? Does that make sense? Before the "master feature" is built? As I mentioned in bug 378191, there is a special fetch_org.eclipse.swt.win32.wce_ppc.arm task (if it doesn't exist yet), so one theory is its fetched at that point, built and packaged for the standalone jars? Then _later_ the plugin is attempted to be re-compiled and then the errors occur? So, basically the last think "on disk" would be junk, but luckily the standalone part takes place first so is ok? I've added an echo to the custom "fetch" task to see if its really fetching anything there, or if already has been and already exists? The "fetch" occurs on line 175031 And the first compile error on line 175513 In between, on line 175095, the SWT class appears to compile ok: 175095 [javac] [parsing /opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.swt.win32.wce_ppc.arm/temp.folder/ws/win32/swt.jar.bin/org/eclipse/swt/SWT.java - #1/462]
And, meant to say, if true, that means the plugin could be removed from the master feature, as suggested -- for the wrong reasons -- in bug 378191.
The SWT standalone custom build scripts were called as one of the last steps in the build, called in the publishEclipse target which then called buildStandaloneSWT target in the helper.xml file. The reason that these obscure fragments were included in the master feature is because they are not built as platforms in the regular sdk build and thus had to be fetched separately. The SWT team still wanted these standalone win arm to continue to be built, but they were not automatically included in any regular features.
(In reply to comment #7) > The SWT standalone custom build scripts were called as one of the last steps in > the build, called in the publishEclipse target which then called > buildStandaloneSWT target in the helper.xml file. The reason that these > obscure fragments were included in the master feature is because they are not > built as platforms in the regular sdk build and thus had to be fetched > separately. The SWT team still wanted these standalone win arm to continue to > be built, but they were not automatically included in any regular features. Thanks Kim. I figured it was something like that, but then saw the helper.xml file had its own fetch capability "if it wasn't there" ... so ... seemed odd. With some debug statements, and and a test run, I do see that it does detect it as being there already, so does not do the fetch and generation in the helper.xml file. But, almost seems its being compiled twice, maybe by two parallel processes? Just to be sure ... since moving to build.eclipse.org one difference is the exact VMs or libraries being used ... this doesn't take a special VM or libraries, does it? What we currently are set up with are: bootclasspath="/shared/common/j2sdk1.4.2_19/jre/lib/rt.jar:/shared/common/j2sdk1.4.2_19/jre/lib/jsse.jar:/shared/common/j2sdk1.4.2_19/jre/lib/jce.jar" bootclasspath_15="/shared/common/jdk-1.5.0_16/jre/lib/rt.jar:/shared/common/jdk-1.5.0_16/jre/lib/jsse.jar:/shared/common/jdk-1.5.0_16/jre/lib/jce.jar" bootclasspath_16="/shared/common/jdk1.6.0_27.x86_64/jre/lib/rt.jar:/shared/common/jdk1.6.0_27.x86_64/jre/lib/jsse.jar:/shared/common/jdk1.6.0_27.x86_64/jre/lib/jce.jar" bootclasspath_foundation="/shared/common/org.eclipse.sdk-feature2/libs/ee.foundation-1.0.jar" bootclasspath_foundation11="/shared/common/org.eclipse.sdk-feature2/libs/ee.foundation.jar" # https://bugs.eclipse.org/bugs/show_bug.cgi?id=375976, and # https://bugs.eclipse.org/bugs/show_bug.cgi?id=376029 OSGiMinimum11="/shared/common/org.eclipse.sdk-feature2/libs/ee.minimum.jar" OSGiMinimum12="/shared/common/org.eclipse.sdk-feature2/libs/ee.minimum-1.2.0.jar"
marking this old was as dup of more recent one, since it has more definitively information. *** This bug has been marked as a duplicate of bug 388091 ***
