Bugzilla – Full Text Bug Listing
| Summary: | Classes from an unresolved fragment used by the host | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Oleg Besedin <ob1.eclipse> | ||||||||||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | P3 | CC: | darin.eclipse, ob1.eclipse, pwebster | ||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Target Milestone: | 3.6 M4 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows XP | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Bug Depends on: | |||||||||||||||||
| Bug Blocks: | 294196 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Oleg Besedin
Created attachment 151313 [details]
Demo of the problem
This is an illustration of the problem:
- Make sure both Java 1.4 and Java 1.5 VMs are made available in Eclipse
- Add bundle and fragment from the zip to the workspace
- Run it as Eclipse app using Java 1.5 VM. Use "Sample menu" -> "Sample Action". It works as expected - output in the console and the message box
- Run it using Java 1.4 VM. Nothing happens there is an "UnsupportedClassVersionError" exception (see the error log)
===
The example was made in the following way:
The project "abc" is build using "Hello World" template. Its EE set to Java 1.4
The project "abc.fragment" is build using a wizard for fragment's. Its EE is set to Java 1.5
The fragment's bundle class path set to "abc.jar"; rename build library in build.properties to "abc.jar"
The host's bundle class path set to "abc.jar, ."
Both host and fragment get a class testing123.myTest that prints "Java14" or "Java15". It is called from the SampleAction.
Created attachment 151314 [details]
Exception stack
Created attachment 151329 [details]
possible fix
Possible fix.
Attached is a possible fix. This should only be an issue when the fragment is in your workspace and you are self-hosting. The problem is the dev classpath support in the framework. PDE puts an absolute path to the bin/ folder of the fragment and correctly places that in front of the bin/ folder of the host project. The problem is that we do not check if the fragment where the absolute path is located is actually attached at runtime. This fix builds on the fix to bug 267238 and will fail to add an absolute classpath to the development (self-hosting) runtime class path for the host bundle if the fragment is not currently attached. Question to Darin: Does PDE ever stick other absolute paths in the dev.properties for a bundle that may not be contained in a fragment? If so this fix will break that case. It only will allow an absolute path from dev.properties if it is contained in a fragment that is currently attached. (In reply to comment #4) > Question to Darin: Does PDE ever stick other absolute paths in the > dev.properties for a bundle that may not be contained in a fragment? If so > this fix will break that case. It only will allow an absolute path from > dev.properties if it is contained in a fragment that is currently attached. PDE uses absolute paths for output folders that are linked, as well as for fragments. (In reply to comment #5) > PDE uses absolute paths for output folders that are linked, as well as for > fragments. OK, another solution will be needed. We may need to have PDE add some markup to absolute entries coming from a fragment so that I can do the proper check only for that case. For example, host.bundle.name = @fragment:<path to output folder>, bin The framework can look for @fragment: at the start of the dev path to know that this path should come from a resolved fragment. (In reply to comment #6) > OK, another solution will be needed. We may need to have PDE add some markup > to absolute entries coming from a fragment so that I can do the proper check > only for that case. For example, > host.bundle.name = @fragment:<path to output folder>, bin > The framework can look for @fragment: at the start of the dev path to know that > this path should come from a resolved fragment. I assume Equinox owns the format of this file? (Just concerned about any other tooling that might be generating/reading this file - I don't know of any but wanted to confirm). As far as I know the runtime is the own client of this file. The old format will still work we just wont do the extra fragment attachment check if the @fragment: prefix is not used. Darin, if you could point me to the PDE code that figures out to add an absolute path to the fragment project output folder I can provide a patch and test it out with a fix to the framework. The code is in org.eclipse.pde.internal.core.ClasspathHelper. It ain't pretty. Created attachment 151515 [details] PDE + framework patch (In reply to comment #9) > The code is in org.eclipse.pde.internal.core.ClasspathHelper. It ain't pretty. Yeah, none of this is pretty. Here is a patch that adds @fragment@ to the paths to classpath entries we expect to come from fragments. Darin, do you want a separate bug for the PDE changes or can we track both the framework and PDE changes with this bug? We can use bug 294196 for the PDE half. Created attachment 151617 [details]
Updated PDE + framework patch
Darin found an issue with the last patch that makes it fail on Linux. It makes the Path look like it is relative and then that path gets removed from the list because we are expecting absolute paths in this case.
Here is an updated patch that postfixes the @fragment@ annotation. Unfortunately I have not been able to test this patch yet. PDE is not allowing me to export a jar'ed bundle into the installation of my eclipse. It keeps exporting the bundle as a directory bundle. I have no idea why but that really messes up an installation if the bundle you are trying to patch happens to be org.eclipse.osgi. It totally busted my eclipse and I could not recover I had to resort to reinstalling eclipse from scratch.
Created attachment 151621 [details] Updated PDE + framework patch (In reply to comment #13) > Created an attachment (id=151617) [details] > Updated PDE + framework patch Ignore the last patch, I accidentally reattached the previous patch. Patch looks good. Ping. Having this fix would allow us to properly use different code paths depending on the VM (Java-1.4 vs. Java-1.5+) for dependency injection in E4. I released the org.eclipse.osgi patch. Still need the core.pde portion of the patch released under bug 294196. Darin, can you release that portion of the patch? Released fix to PDE. Marking as fixed. |