Community
Participate
Working Groups
Build I200406110010 0. New workspace. Autobuild OFF. 1. Set Plug-in Dev > Target Platform preference to include just these plug-ins: org.eclipse.core.runtime org.eclipse.osgi org.eclipse.osgi.services org.eclipse.osgi.util org.eclipse.swt org.eclipse.swt.win32 2. Load org.eclipse.jface project from dev.eclipse.org repo 3. In Package explorer expand org.eclipse.jface/Plug-in Dependencies. Observe: dependencies includes swt.jar 4. Build All Observe: No compile errors. 5. Load org.eclipse.swt and org.eclipse.swt.win32 projects from dev.eclipse.org repo. Observe: As the projects are being loaded, JFace plug-in dependencies drop swt.jar and picks up org.eclipse.swt project. 6. Build All Observe: Fatal compile errors. SWT cannot be build (this is expected). JFace cannot be built either because it depends on SWT (also expected). 7. Delete org.eclipse.swt and swt.win32 projects from workspace. Observe: After the project has been deleted, dependencies drops org.eclipse.swt project. Expectation: By symmetry, it pick up swt.jar when it drops org.eclipse.swt project. This is problem #1. 8. Build All Observe: Numerous compile errors. Cannot resolve references to SWT classes. 9. Close JFace project. 10. Open JFace project. Observe: Package explorer shows org.eclipse.jface plug-in dependencies as including org.eclipse.swt. Goodness again, or so it seems. This shows that PDE is correctly computing classpath container when project is opened. 11. Build all Observe: The build is a no-op. Numerous compile errors remain. Expectation: Given the switch between swt.jar and the project, JFace needs to be thoroughly re-compiled, which should take several seconds. This looks like problem #2. I believe the built state was saved when the project was closed, and restored when it was reopened. The fact that PDE now computes different contents for the classpath container is not, but should, invalidate that built state. 12. Clean and build Observe: JFace compiles without errors. Observe: No compile errors. Goodness again.
I was able to reproduce this. Need to investigate and fix. Dejan, +1 for RC3?
Depends on the nature of fix. Append the results of the investigation and value/risk ratio.
Value: Extremely High Risk: Extremely Low While, on the surface, this seemed like a flaw in classpath computation or pde container updating, the opposite is actually true. In fact, the classpath computation exposed a flaw in the way we store/read version numbers. Let me explain... Back toward the end of the M9 cycle, the Core team introduced a new syntax to represent bundle version/match. Old format: bundle-version:3.0.0;match=compatible New format: bundle-version="[3.0.0,4.0.0)" When we scan/resolve the target platform to populate our old models with the new data, here is how map the new format to our 2.1-compliant data structures: Given the range, we take the minimum (ie. 3.0.0) to map it to the old meaning of version. With a very simple algorithm, the "match" is deduced from the range. In this case, this range maps to the old "COMPATIBLE". This is all fine. The problem arises when PDE reads the manifests from workspace plug-ins directly. In these cases, we are storing the version as-is. So if org.eclipse.swt.win32 is in the workspace, we store its version as "[3.0.0,4.0.0)". So when we come to find all fragments belonging to org.eclipse.swt to search for the swt libraries, we don't get any match because when we pass [3.0.0,4.0.0) to PluginVersionIdentifier, an exception is thrown, so we fall back on a string comparison, which of course fails. Here is a breakdown of what was happening in Jim's scenario: 1. He checks out org.eclipse.jface from cvs. It classpath is complete because the external org.eclipse.swt.win32 and org.eclipse.swt have the right versions stored. 2. He then checks out org.eclipse.swt and swt.win32 from cvs. Classpath here is also correct because we don't add workspace fragments directly to the classpath. So the org.eclipse.swt plugin project gets directly added to the classpath of org.eclipse.jface. Note that so far, the flaw in the way we store the version/match attributes in the swt.win32 has not been exposed. 3. Delete org.eclipse.swt and org.eclipse.swt.win32. By the way, the problem is only exposed when the fragment is deleted after its parent plugin. Now, the swt plugin is deleted, so the classpath computation of org.eclipse.jface is triggered. PDE doesn't find swt.jar in the external org.eclipse.swt, of course, because the JAR is shipped in the fragment in the SDK. So we start looking for the JAR in the fragment(s). We first look for fragments in the workspace as they mask the external ones. The org.eclipse.swt.win32 fragment is still not technically deleted at this point, so we call our PDE.compare() utility on it to make sure that it matches the version and the compatibility with the org.eclipse.swt plugin. This comparison fails because we are comparing [3.0.0, 4.0.0) with 3.0.0. So no workspace fragments were found for the plugin. And of course, no external fragments are hit because the workspace fragment had masked the external one. So the classpath is now incomplete as PDE could not find swt.jar. Therefore, the fix would entail fixing BundleFragment.getVersion() and BundleFragment.getRule() to parse the version ranges of the new manifest format and return corresponding values that are familiar to every other aspect of PDE.
+1
Created attachment 12281 [details] Patch for pde-core Dejan, please review patch.
Marking as fixed. Will be in today's 4 pm build. Jim, please verify the fix and thank you for catching this bug in time.
Verified on I20040618-0800.
