Community
Participate
Working Groups
Adding various EclipseLink 2.0.0 bundles to the required-bundles of an RCP bundle results in a complete failure of PDE validation. "Complete" in that the bundles that were previously revolved are now marked with errors and all imports are unresolvable. For example, in the Hello RCP example generated by the wizard, adding org.eclipse.persistence.jpa 2.0.0 to the required-bundles results in an "Unsatisfied version constraint: 'org.eclipse.ui:0.0.0'" error. A similar error is attached to org.eclipse.core.runtime. With all required bundles no longer resolved all of the imports and class references in the plugin generated by the wizard produce compilation errors. The EclipseLink 2.0.0 bundles deploy and run fine on Equinox 3.5. This behavior is not reproducible with the same EclipseLink 2.0.0 bundles in Eclipse 3.4 so this is some sort of regression. To reproduce: o Use Eclipse 3.5 or 3.5.1 with PDE o Download EclipseLink 2.0.0 OSGi bundles (P2 repository not yet available for this release) http://www.eclipse.org/eclipselink/downloads/index.php#2.0.0 o Either expand target to include downloaded EclipseLink bundles or drop them into dropins--problem manifests either way o Create a new "Hello RCP" project with the wizard. o Add org.eclipse.persistence.jpa as a required bundle. A number of other EclipseLink bundles produce the same problem. Note: EclipseLink 2.0.0 uses BND to generate manifests so they are fairly verbose. I suspect we're seeing some kind of BND/PDE incompatibility. Any suggestions on how to change the EclipseLink manifests to work around this problem would be appreciated as we can make those changes in our upcoming 2.0.1 patch release.
The issue might be related to missing reexported packages. Need to investigate further.
some notes by me: I have fought with this problem before several weeks because I like to attempt the official JPA 2.0 API in the head:) one thing is the version of my eclipse is 3.6M4. For my testing, the PDE will report the "Unsatisfied version constraint" errors when the PDE really think that there are really some errors in the bundles. If the head of codes don't report errors under the e3.4, I guess the problem may be in the current validation rules of PDE. However, I make my own nice eclipselink JPA 2.0 bundles, which is working with 3.6M4 PDE. I don't modify any codes. I just re-arrange the relationships between the bundles. (Why I do this? Because, in my original idea, I don't think PDE has any problem, and think there are really some errors in eclipselink source.) One other thing is, I think the huge bundle "org.eclipse.persistence.core" should be refactored into small bundles. It is a big bad smell in the current eclipselink sources. (many things in the core bundle seem not needed for the JPA)
Sigh, I'll look at this. BND is generating A LOT of uses clauses for EclipseLink...
Thanks Chris! Like I'd said in my initial comment we have an opportunity in our EclipseLink 2.0.1 release to make changes to our manifests so any feedback is definitely welcome. --Shaun
Ok, I managed to reproduce this. I'm bumping the severity to blocker. When you add 'org.eclipse.persistence.jpa' as a dependency (via Require-Bundle) the PDE classpath container disappears. We will have to fix this for 3.5.2 Shaun, when do you plan on doing a 2.0.1 release?
Ok, I've debugged this further. The state from Equinox is giving us some unexpected results, not sure why yet. Essentially, we process the PDE model change: org.eclipse.pde.internal.core.PluginModelManager.modelsChanged(...) When then go resolve the state incrementally based on the changes. When we go through the BundleSpecification's for the required bundles, the supplier comes back as null for everything process. BundleSpecification[] required = desc.getRequiredBundles(); for (int i = 0; i < required.length; i++) { addDependency( (BundleDescription) required[i].getSupplier(), added, map, entries); } I'm not sure why yet. I'm cc'ng Tom for some Equinox state debugging help.
The current proposed date for EclipseLink 2.0.1 is Feb. 17th but it isn't in stone. There is talk of bringing that date in so we can release a P2 repository for EclipseLink 2.0.x asap.
I spent some time debugging this and found that it is really a "uses" directive constraints violation which has no valid solution to allow a bundle which requires org.eclipse.core.runtime and one of the jpa bundles (org.eclipse.persistence.jpa) to resolve. The issue is the ever present evil of the org.eclipse.core.runtime's use of re-export for the org.eclipse.osgi bundle. Any bundle which requires org.eclipse.core.runtime will be wire indirectly to org.eclipse.osgi which happens to be the system bundle. This bundle exports a number of packages from the VM (including javax.xml.stream, javax.transaction, and javax.activation stuff depending on the VM being used). The issue is the EclipseLink 2.0 set of bundles contains some bundles which also export these packages and other bundles in EclipseLink 2.0 get wired to these bundles for the javax.* packages AND they have exports which contain a "uses" clause to one or more of the javax.* packages. The end result is that a bundle which requires org.eclipse.core.runtime and one of these EclipseLink 2.0 bundles is not allowed to resolve because it will introduce a uses conflict between what org.eclipse.core.runtime is providing for the javax.* packages and what the EclipseLink 2.0 bundle thinks must be used for the javax.* packages. To work around the issue I was able to add a Require-Bundle: system.bundle to the following bundles in EclipseLink 2.0: javax.activation_1.1.0.v200806101325 javax.transaction_1.1.0 javax.xml.stream_1.0.1.v200903100845 I'm not sure if this is the correct thing to do in this case. Essentially this splits the exported packages from these bundles between what may be provided by the VM (through system.bundle exports) and what is contained in the individual bundles. In other words the classes provided by the VM will take precedence over the ones provided by the individual bundle. This helps avoid the uses constraint violation between the EclipseLink 2.0 bundles and the org.eclipse.core.runtime bundle.
Tom, based on your comments I think the simplest thing to do is to edit the target platform to remove the bundles that conflict with packages that are provided by the JRE. JRE 5 did not include javax.activation, javax.transaction, or javax.xml.stream. Their inclusion in JRE 6's rt.jar is the source of the conflicts. I just tried this out and was able to compile and deploy a trivial RCP app from PDE. Correct me if I'm wrong but I think the EclipseLink bundle manifests are fine (even with all the uses) and that by reducing the source of the various used packages to only the system bundle we eliminate the problem. Now we just have to figure out what this means to our P2 features--we apparently need a different set of bundles for different JRE versions!?
(In reply to comment #9) > Tom, based on your comments I think the simplest thing to do is to edit the > target platform to remove the bundles that conflict with packages that are > provided by the JRE. JRE 5 did not include javax.activation, > javax.transaction, or javax.xml.stream. Their inclusion in JRE 6's rt.jar is > the source of the conflicts. I just tried this out and was able to compile and > deploy a trivial RCP app from PDE. > > Correct me if I'm wrong but I think the EclipseLink bundle manifests are fine > (even with all the uses) and that by reducing the source of the various used > packages to only the system bundle we eliminate the problem. I think you are correct, but If the javax.* packages are acceptable on JRE 6 then I would still recommend adding the Require-Bundle: system.bundle in the javax.* bundle manifests. This will force the use of the javax.* packages from the VM if they are available. > > Now we just have to figure out what this means to our P2 features--we > apparently need a different set of bundles for different JRE versions!? This is why I make the recommendation to add the Require-Bundle system.bundle to the javax.* bundles. I think making different features depending on the JRE version is going to be a rat hole. An alternative would be to try and make the javax.* bundles unresolvable on JRE 6 or higher but there currently is no OSGi way to express this kind of constraint in a bundle manifest. The Bundle-RequiredExcecutionEnvironment header does not express things like this.
Ok thanks Tom. I've entered Bug 298949 to add system.bundle to the bundles you identified. But something I said was incorrect. I had failed to properly test on JDK 5. I revisited this and when I switched to JDK 5 and left the three problem bundles in my target environment I still got what appears to be the same failure. JDK 5's rt.jar does include javax.transaction. I've set the status to RESOLVED/WONTFIX as you suggest that org.eclipse.core.runtime's re-exports are at the root of this and they are going to be left as is. If these are not the correct status values please update.
I opened bug 298959 to address some of the classpath container issues that came up when debugging this. This is the first case that I saw the classpath container not work.
One more question. Is the requiring of system.bundle a general solution that should be applied to all javax.* bundles who's contents may be in part or entirely included in different versions of the JRE? Two of the bundles we've identified are coming out of Orbit so changes will have to be made there. But Orbit contains a number of other javax.* bundles that could produce the same problem, like javax.management. If we fix the ones we know about shouldn't we fix the others? I'm looking for direction before I file the Orbit bug. :)
(In reply to comment #13) > One more question. Is the requiring of system.bundle a general solution that > should be applied to all javax.* bundles who's contents may be in part or > entirely included in different versions of the JRE? > > Two of the bundles we've identified are coming out of Orbit so changes will > have to be made there. But Orbit contains a number of other javax.* bundles > that could produce the same problem, like javax.management. If we fix the ones > we know about shouldn't we fix the others? I'm looking for direction before I > file the Orbit bug. :) In general I think we should look into doing this. But we may need to do it on a case by case basis. If the version the VM provides is acceptable to eclipse then we should add Require-Bundle: system.bundle to these bundles. For example, the javax.xml bundle has this header.
Filed Bug 299313 and Bug 299312 for javax.activation and javax.xml.stream, respectively.
For the record. I encountered this issue when defining a dependency to both org.eclipse.persistence (EclipseLink) and org.eclipse.core.runtime in the Manifest.MF of a plugin. To workaround this issue I changed the dependency like this: I re-moved the direct plugin dependency (org.eclipse.core.runtime) and added the needed java packages to the import-packages part of the Manifest.MF. The org.eclipse.persistence remained a direct plugin dependency. This solved it for me. gr. Martin
