Bugzilla – Full Text Bug Listing
| Summary: | Update site project builds ignore project specific Java compliance levels. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Gary Mohr <Gary.Mohr> | ||||
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | michael.giroux, mober.at+eclipse, pombredanne | ||||
| Version: | 3.1.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Gary Mohr
I'm using Eclipse 3.2 and have a similar problem. The java compliance for the workspace is set to 1.5. The compliance for my plugin project is set to 1.4. If I do a clean on the project, then check the class files in /bin, all are compiled w/ 1.4 compliance. If I launch the plugin using pde launch, the classes on the plugin classpath are indeed 1.4 compliance (since they come from /bin) However, if I export the plugin using the export wizard the class files that are packed into the library.jar for the plugin are 1.5. As a result, the plugin classes cannot be loaded w/ jdk 1.4. It appears that when the plugin is exported, the export wizard uses the global workspace settings, and ignores the project settings. I tried using the new 3.2 manifest directive: Bundle-RequiredExecutionEnvironment: J2SE-1.4 but this caused a problem when loading the plugin in Eclipse 3.1. Created attachment 47786 [details]
Sample project that shows project-local compliance and incorrect generated build.xml
I guess I have the same problem. Using Eclipse 3.2.
I'm using the default compliance settings in my workspace.
I have one plugin with project-specific options set to 1.4.
Locally, everything builds fine.
But the nightly builds, which are done using PDE build / ant, cannot compile the class files (they don't understand the "assert" keyword).
To test this, I selected the "Manifest.mf" file and chose "PDE Tools > Generate ant build file". In the generated build.xml file, I see compliance settings
<property name="javacSource" value="1.3"/>
<property name="javacTarget" value="1.2"/>
I'm setting severity to "major" since I do not understand how I could make my nightly builds eat the assert keyword properly.
Find attached my project, including the proper .settings directory and the incorrect generated build.xml file.
Hmm... Just noticed that this is probably a duplicate of bug 134855. There, it's explained that the headless build has no access to the project properties (and update site builds are headless). But the headless build should evaluate the Bundle-RequiredExecutionEnvironment setting from Manifest.mf, which I have set correctly. So IMHO, there are two possibilities for a bug: 1) It's by design that headless build cannot evaluate Manifest.mf properly and only looks at build.properties. Then, I'd expect the UI where I set the properties to automatically update the build.properties file. Note that I have made all changes through the UI only. 2) Headless build should be able to evaluate Manifest.mf. The JVM that I'm building on is IBM-5.0, and my RequiredExecutionEnvironment is J2SE-1.4. Perhaps the headless build didn't put the settings right because there was no exact match? I'd appreciate if someone from the PDE build team could look at my attachment and come up with an explanation. By default J2SE-1.4 maps to 1.3/1.2 for source/target levels. To override this for assert, set the properties javacSource=1.4 and javacTarget=1.4 in your bundle's build.properties file. The headless build does evaluate the Bundle-RequiredExecutionEnvironment header. I have noticed occasionally that this doesn't work for some reason, I have raised bug 153778 to figure this out. When setting the execution environment, you should expect your build.xml to contain something like the following: <condition property="bundleBootClasspath" value="${J2SE-1.4}"> <isset property="J2SE-1.4"/> </condition> <condition property="bundleJavacSource" value="1.3"> <isset property="J2SE-1.4"/> </condition> <condition property="bundleJavacTarget" value="1.2"> <isset property="J2SE-1.4"/> </condition> At build time, the property J2SE-1.4 is checked. When using the UI, this property should be automatically set based on your preferences (See Java->installed JREs->Execution Environments). In a headless setup, this property is expect to be set in the builder configuration build.properties. See Marking as a duplicate. This may initially have been a setup issue, which my previous comment addresses. See also http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_compilation_env.htm There is a case where there is an actual bug, which is 153778 *** This bug has been marked as a duplicate of 153778 *** (In reply to comment #5) > Marking as a duplicate. This may initially have been a setup issue, which my > previous comment addresses. My point is, that when I edit project-specific preferences in the JDT GUI, and change the compiler compliance settings to 1.4-with-assert, I'd expect the build.properties file to be updated automatically. Otherwise it's just too easy to break the headless (or update site) build with something that seems to work fine (as long as no headless build is done). Perhaps that would be worth a separate enhancement request? Yes please. That kind of enhancement would be on PDE/UI. Please reference the Feature Request here so I can vote on it. Enhancement request created as bug 154292 |