Community
Participate
Working Groups
I bug 466775 we tracked that all stuff we require from javax.xml is provided by the JRE and we should get rid of this old javax.xml stuff and directly use the JRE provided versions. To use the JRE versions all imports who bind to javax.xml should be changed to unversioned imports and javax.xml should not be delivered by the Platform anymore.
+1 Hurra
New Gerrit change created: https://git.eclipse.org/r/57946
Dani, Do we need some announcement before removing bundles from the platform? I fully agree we should remove the javax.xml bundles, but I think our policies require some notice to the community. Also, this patch removes the bundle from the feature. I assume all the require-bundle: javax.xml have been adjusted to import-package. Keep in mind all third-party plugins would need to do the same so that is why I think we need to make advanced notice to the community before doing this.
(In reply to Thomas Watson from comment #3) > Dani, Do we need some announcement before removing bundles from the > platform? Well, first you need to get PMC approval explaining why this is necessary after the API freeze. Send a note to the pmc-list if you really want to do this for 4.6. Personally I'd prefer 4.7.
I know that WTP was using javax.xml (IIRC through Xerces?)
Mass move to 4.6 RC1. We might push out more to 4.7.
IMHO, it's the right time to give a try to that removal. For 4.7, all dependent projects will have time to react and if it's causing an issue, it will be noticed by Simrel Oxygen RC3. @Thomas: can you take care of sending the note to PMC and of the "administrative" part of that change?
Unfortunately no - I'm currently not able to put time into Eclipse Platform stuff.
I suggest to remove the javax.xml early M5 so that project have time to react.
Tom suggested that this should be decided by the PMC. I add this to our next call.
Just as a side note - e(fx)clipse RCP application run with a javax.xml replacement who delegates to the JRE without ANY problems!
(In reply to Thomas Schindl from comment #11) > Just as a side note - e(fx)clipse RCP application run with a javax.xml > replacement who delegates to the JRE without ANY problems! Thanks, that's good news. I'm +1 to remove it, but first you have to announce this on the cross-project-issues-dev mailing list where you explain what will happen and detailed instructions what the projects have to do. I suggest you do this asap and announce the deletion for M6. Once the message is sent, I'll give the PMC approval on this bug. Together with the deletion you also have to add an entry to the migration guide.
If you want to fix this for 4.7, you need to act now.
(In reply to Dani Megert from comment #13) > If you want to fix this for 4.7, you need to act now. Eamil to cross https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14096.html
I suggest to wait a week and then go ahead.
(In reply to Dani Megert from comment #15) > I suggest to wait a week and then go ahead. +1.
Gerrit change https://git.eclipse.org/r/57946 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e9abb6dd53dce7eaec99100b970ff40f904f9f11
This is not done yet. From comment 12: "Together with the deletion you also have to add an entry to the migration guide." And it needs an N&N entry.
I just updated my Oxygen installation and face an issue with this change. !MESSAGE Could not resolve module: org.eclipse.e4.ui.css.swt.theme [33] Unresolved requirement: Require-Bundle: org.eclipse.e4.ui.css.swt; bundle-version="0.9.1" -> Bundle-SymbolicName: org.eclipse.e4.ui.css.swt; bundle-version="0.13.0.qualifier"; singleton:="true" org.eclipse.e4.ui.css.swt [32] Unresolved requirement: Require-Bundle: org.eclipse.e4.ui.css.core; bundle-version="0.9.0" -> Bundle-SymbolicName: org.eclipse.e4.ui.css.core; bundle-version="0.12.100.qualifier"; singleton:="true" org.eclipse.e4.ui.css.core [31] Unresolved requirement: Import-Package: org.w3c.dom.css; version="2.0.0" javax.xml also provides the org.w3c.dom.css package in version 2.0.0. Which bundle provides this package now? There is a bundle dependency but it seems to be not provided by the JRE. At least my application is not starting anymore. Any hints?
OK, the org.w3c.dom.css and org.w3c.dom.stylesheets bundle is also provided by the JRE. But there we don't have a version constraint. So the dependencies in org.eclipse.e4.ui.css.core needs to be modified. The version constraints on the package imports need to be removed in order to make it work again.
New Gerrit change created: https://git.eclipse.org/r/90882
I'm not sure but it looks like the same issue applies to some Equinox bundles. At least I get some warnings for org.eclipse.equinox.registry where the javax.xml packages are specified with a 0.0.0 version constraint. The warning is raised by PDE if I start with the -console parameter. Not sure how this is related. But it looks like some additional checks need to be done in Equinox aswell.
(In reply to Dirk Fauth from comment #22) > I'm not sure but it looks like the same issue applies to some Equinox > bundles. At least I get some warnings for org.eclipse.equinox.registry where > the javax.xml packages are specified with a 0.0.0 version constraint. > > The warning is raised by PDE if I start with the -console parameter. Not > sure how this is related. But it looks like some additional checks need to > be done in Equinox aswell. What does the warning say? The org.eclipse.equinox.registry already imports the xml packages with no version constraint.
I think the problem is PDE who is not smart enough to find out what JRE/JDK you try to run on, hence it does not find out that javax.xml is part of the JRE (same is true for the Target-Platform UI) because the Java8 EE contains it. In e(fx)clipse we ship an EMPTY java.xml bundle to satisfy PDE in both cases!
(In reply to Thomas Schindl from comment #24) > I think the problem is PDE who is not smart enough to find out what JRE/JDK > you try to run on, hence it does not find out that javax.xml is part of the > JRE (same is true for the Target-Platform UI) because the Java8 EE contains > it. > > In e(fx)clipse we ship an EMPTY java.xml bundle to satisfy PDE in both cases! When you mentioned this it made me think the issue is because equinox.registry still claims it supports J2SE-1.4 BREE (something I think needs to be updated at some point). But the required xml packages are available on J2SE-1.4. So PDE should not complain here about that missing.
Created attachment 266787 [details] warning screenshot I get this validation error on starting. Interestingly org.eclipse.equinox.registry starts and is in ACTIVE state. So it seems to be a PDE issue.
(In reply to Dirk Fauth from comment #26) > Created attachment 266787 [details] > warning screenshot > > I get this validation error on starting. Interestingly > org.eclipse.equinox.registry starts and is in ACTIVE state. So it seems to > be a PDE issue. What is interesting here is that only the org.eclipse.equinox.registry has the issue. My understanding is many other bundles in your testing import the xml packages in the same way. This brings me back to suspecting something is going wrong with the BREE being J2SE-1.4 while I suspect all the other bundles are at a much later BREE. If I recall correctly there is a PDEState object that is used to validate the set of bundles for launch. In that state it is supposed to be loaded with all the supported execution environments by calling: org.eclipse.osgi.service.resolver.State.setPlatformProperties(Dictionary<?, ?>[]) Where each Dictionary represents a supported execution environment. One of the properties in the dictionary is supposed to contain the available packages for the execution environment ("org.osgi.framework.system.packages"). Perhaps somewhere along the way the java profile for J2SE-1.4 is losing this information for the PDEState.
Gerrit change https://git.eclipse.org/r/90882 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b360024e3f5a66b3e846c7e174e9065c734f9f34
(In reply to Thomas Watson from comment #27) I suggest to open a separate bug against PDE.
(In reply to Dirk Fauth from comment #26) > Created attachment 266787 [details] > warning screenshot > > I get this validation error on starting. Interestingly > org.eclipse.equinox.registry starts and is in ACTIVE state. So it seems to > be a PDE issue. I also got this with I20170219-2000. If you disregard it, it seems to start without issues though.
(In reply to Dani Megert from comment #29) > (In reply to Thomas Watson from comment #27) > > I suggest to open a separate bug against PDE. Done bug 512424
As a related note, I noticed because of this change that org.apache.xerces also "requires bundle" javax.xml. So eventually it could be good for Orbit to go through a similar removal process. Because our product (Trace Compass) includes some Web Tools dependencies that depend on org.apache.xerces, we also have to make sure javax.xml is included. I'm not sure if it will affect some EPPs but I thought I'd mention it.
Mass move. Please move back to M6, if necessary
(In reply to Lars Vogel from comment #33) > Mass move. Please move back to M6, if necessary I'm unsure about this. Actually most of the jobs are done. Despite the open topics in PDE (separate ticket) and maybe some side effects we haven't noticed yet. But from my understanding javax.xml is removed and the modifications in the platform are done. Or is there something still open?
(In reply to Dirk Fauth from comment #34) > (In reply to Lars Vogel from comment #33) > > Mass move. Please move back to M6, if necessary > > I'm unsure about this. Actually most of the jobs are done. Despite the open > topics in PDE (separate ticket) and maybe some side effects we haven't > noticed yet. But from my understanding javax.xml is removed and the > modifications in the platform are done. Or is there something still open? The migration entry is missing. Lars told me that he will fix it for M6. Lars: only a few hours left ;-).
(In reply to Dani Megert from comment #35) > (In reply to Dirk Fauth from comment #3 > > Lars: only a few hours left ;-). Cloning the Commons repo timed out yesterday night in the hotel, will try again tonight. Will be late (> 22:00 CET) so if that is after the cutoff, please move to M7.
Cloning the commons repo continue to hang between 67-69%. Moving out to M7 and to a better Internet connection that hotel WLAN.
We are getting close to M7 now.
New Gerrit change created: https://git.eclipse.org/r/96574
Gerrit change https://git.eclipse.org/r/96574 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=32ac6de556bd15b7902a5120b579c3343e4a2169
Migration guide entry added.
(In reply to Marc-André Laperle from comment #32) > As a related note, I noticed because of this change that org.apache.xerces > also "requires bundle" javax.xml. So eventually it could be good for Orbit > to go through a similar removal process. > > Because our product (Trace Compass) includes some Web Tools dependencies > that depend on org.apache.xerces, we also have to make sure javax.xml is > included. I'm not sure if it will affect some EPPs but I thought I'd mention > it. Marc-André: how it was fixed on your side for org.apache.xerces? I'm now trying to update our 4.6 Oomph based IDE to 4.7.1 and have exact same issue that Web Tools (still) includes (ancient) xerces which still "requires bundle" javax.xml. Funny enough they include this inside the feature, but Oomph p2 installer denies to "see" this bundle and says that javax.xml is missing.
