Community
Participate
Working Groups
I've been having fun with the org.eclipse.releng.eclipsebuilder (R3_1_1) today, and I've discovered an incompatibility with the generated plugin build files and Mac OS X. The generated build file for a plugin has: <path id="path_bootclasspath"> <fileset dir="${java.home}/lib"> <include name="*.jar"/> </fileset> </path> However, ${java.home} on a Mac is /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home whereas the actual runtime classes are in /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes So this doesn't work on a Mac; you get compile time errors that say 'Cannot find java.lang.Object' which sounds like a serious error :-) The solution would be to generate (on a Mac) <fileset dir="${java.home}/.."> <include name="Home/*.jar"/> <include name="Classes/*.jar"/> </fileset> or better still, don't specify a boot classpath :-) This was tested under Mac OS X 10.4.4 with Java 1.4.2 installed (not the Java 5 release that's in development status). I used org.eclipse.releng.eclipsebuilder version R3_1_1, and Eclipse 3.1.2 to act as the base location. The workaround (for anyone else who picks this up) is to specify -Dbootclasspath=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Classes/classes.jar on the argument to your ant script calls, and then that restores order. Note that it may be necessary to specify others as well (e.g. ui.jar or jsse.jar) depeding on your intent; but the wildcards above should work. By the way, I noticed that the basebuilder doesn't have the Mac OS X SWT libraries installed; don't know if that's intentional or an oversight.
basebuilder doesn't include the macosx swt libs because we don't build on macosx, we build on linux-ppc-gtk on a mac g5. we specify a bootclasspath in our build.properties for our needs, so you can always remove it after you have checked it out. If you want any changes made to basebuilder, please provide a patch against the 3.2 stream (v20060210a is what we are using today), since the maintenance stream is closed.
Please reopen with a patch if you want this fixed.
Note that this bug may also manifest itself on a Harmony-VM build, since Harmony doesn't have an rt.jar either.
So far, so good. I've got a patch that fixes the generation of the build files so that I can run it via 'ant' at the command line. It doesn't work with the Eclipse builder process because of some bugs in the PDE JDTCompilerAdaptor, though :-) The problems in the JDTCompilerAdapter are that it adds foreach dir in java.ext.dirs, dir/*. On Mac, the ext dirs may contain both Jars and .jnilib files, which aren't valid entries to be put on the classpath. I've got a fix that I'm still working through testing for the JDTCompilerAdapter (not the least of which is finding out where it's stored) to just add *.jar,*.zip entries from the ext path. The other problem is that the build file generates -log something.log as a compiler argument, and the JDTCompilerAdapter uses -log something.log as well. The Java compiler then barfs at two -log statements on the same line. Commenting out the property that uses the JDTCompilerAdapter works around the problem, but ideally we'd want it fixed in the JDTCompilerAdapter. I'll raise a separate bug (and link it here) with patches in a while.
Created attachment 37139 [details] Adds ${sun.boot.class.path} to generated build file This changes rt.jar to ${sun.boot.class.path} to the generated build file for the default build property. I've tested this against Mac OS X and it seems to work, for command-line ant builds at least (there are some other problems with the JDTAdapter). This has no effect if the bootclasspath is overriden, since the property is never consulted. On Sun-VMs and derivatives, when sun.boot.class.path is set, you'll get similar behaviour (but some VMs may also have other entries on the path). If it's a non-Sun-VM, it may not set sun.boot.class.path and thus cause breaking behaviour. I investigated the possibility of using a pathelement to prepend ${sun.boot.class.path} to a pathref, but it didn't seem to expand the ${sun.boot.class.path} property.
Oh, I probably should have said. Downloaded the plugin from HEAD, so it should be up-to-date. There weren't any other changes I had to merge in.
These are the additional messages generated during build: [javac] incorrect classpath: /Library/Java/Extensions/libsvnjavahl.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3D.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3DAudio.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3DUtils.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libShark.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libmlib_jai.jnilib and, with the 3.2 build, I get an error [javac] duplicate log specification: -log These seems to be problems with the JDTCompilerAdapter (which I'll raise separate bugs for, but wanted to highlight the problems here)
Added bug for other problems that prevent building on Mac OS X. The dependent bug only becomes visible once this bug is fixed.
FYI I've verified that the other bug 133748 fixes the remaining problems on the Mac build. Without this patch, it fails to find the boot classpath since it's not stored in rt.jar. A workaround is to supply -Dbootclasspath=${sun.boot.class.path} which is the equivalent of this patch. I've also tested that sun.boot.class.path is visible on Windows and Linux with Sun VMs; however, it would be useful to know if other non-Sun VMs also provide this property (e.g. kaffe, harmony etc.). Of course, if you're overriding the property at run time anyway then it makes no difference what the default is.
We will no longer will be supporting other teams using our org.eclipse.releng.eclipsebuilder to run their builds. We simply don't have time to modify it to accomodate everyone's requests. If you want to build the SDK, please use the source build. Closing.
Changing OS from Mac OS to Mac OS X as per bug 185991
