Community
Participate
Working Groups
PerspectiveSwitcherCSSHandler.java imports classes from package org.w3c.dom.css. However the org.eclipse.ui.workbench bundle does not import such a package. This is reported as a compile error if you enable the PDE API tools checks. I suspect we are just getting lucky at runtime because most JRE's happen to have a copy of this package. Tom correct me if I'm wrong, but I believe the bundle should still be importing this package in the bundle manifest.
(probably a change for 4.3 unless it is causing runtime problems)
(In reply to comment #0) > PerspectiveSwitcherCSSHandler.java imports classes from package > org.w3c.dom.css. However the org.eclipse.ui.workbench bundle does not import > such a package. This is reported as a compile error if you enable the PDE API > tools checks. > > I suspect we are just getting lucky at runtime because most JRE's happen to > have a copy of this package. Tom correct me if I'm wrong, but I believe the > bundle should still be importing this package in the bundle manifest. Correct, and it just happens to work by default at runtime in equinox because we have a compatibility flag enabled by default that does a last resort boot delegation before throwing a class loading exception. I suspect if you set the following configuration property then you would see a runtime error: osgi.compatibility.bootdelegation=false
Does this package need to be imported for all css bundles then? It seems that it's used heavily in the o.e.e4.css.* bundles as well PW
(In reply to comment #3) > Does this package need to be imported for all css bundles then? It seems that > it's used heavily in the o.e.e4.css.* bundles as well > > PW It should be imported by all bundles that use the org.w3c.dom.css package. The only possible exception would be if the bundle happens to require org.eclipse.osgi. In that case the bundle does get "wired" to all the packages exported by the system bundle as part of the execution environment. Even that is not really a best practice though. So I would recommend that bundles import stuff they need from the execution environment (except java.* packages).
Fixed in master for SR1 PW
The change causes our bundles to require org.w3c.dom.css >= 2.0.0. This change means that we *have* to pull in and ship the javax.xml from Orbit as the version from the system bundle will always be 0.0.0. Must we be specify a package version here? Was there a org.w3c.dom.css version 1.0?
(In reply to comment #6) > the version from the system bundle will always be 0.0.0. Must we be specify > a package version here? Was there a org.w3c.dom.css version 1.0? Tom, do you know if it's OK to just import the package and get rid of the version? I remember from before that exports from the system bundle tend to have 0.0.0. PW
(In reply to comment #7) > Tom, do you know if it's OK to just import the package and get rid of the > version? I remember from before that exports from the system bundle tend to > have 0.0.0. > > PW Yes, I would simply not have the version range for these types of packages. Unfortunately we have never been able to get correct version information for the packages provided by the various Java SE versions.
(In reply to comment #6) > The change causes our bundles to require org.w3c.dom.css >= 2.0.0. Brian, do you want to remove the version attribute from the import? PW
in M20120829-1200 PW
(In reply to comment #10) > in M20120829-1200 > PW I mis-interpreted Paul's remark to mean that he had committed a fix. But this issue happened to me again and is happening to others as evidenced by bugs like bug 387869. Rather than re-opening this bug, I've filed bug 393739.
