Changes to remove the javax.xml must be done across the entire Eclipse
and java stack. Unfortunately, removing the javax.xml in Eclipse breaks
other bundles in too many places preventing Eclipse from discovering
bundles in dropins or even starting. This should not be done in f18.
The launcher was not built properly because Equinox Launcher build
script had no support for arm architectures, therefore it did not knew
where to copy the binary.
javax.xml is provided by the VM so there is no need to bundle it. Due to
inconsistencies in packaging, some errors appear (see RHBZ #710815).
This is removal in a first place (eclipse-dtp and eclipse-mylyn updates
will follow).
Additionally, the binary class was not copied properly into the
compatibility bundle. We can't build it properly (because it was some
old, unknown version), but we can build current version and hope for the
best.
The eclipse-build initial repo with two manifests is now already
unpacked into a right place, so there is no need to move it. Tycho
bundled jars are no longer unpacked, as Tycho manages to work properly
without them now.
mvn-rpmbuild does it automatically, but in this case we are
workarounding an issue with cbi that launchers are built to late and are
not included into final product.
There is an unwanted wiring during bundles resolution here. Many UI
packages required package org.w3.dom.css which was provided by a bundle
in the upstream Eclipse, but is provided by vm SDK in Fedora. The
problem is that it is also provided by javax.xml, and since there are
duplicates, some classes are loaded from javax.xml bundle in some
bundles and others from SDK in other bundles, causing LinkageErrors
and/or class cast exceptions.
The solution is to remove imports from the UI code to ensure that
javax.xml is not searched during class resolution, and that proper
classes from SDK are used.
https://bugzilla.redhat.com/show_bug.cgi?id=861037
Krzysztof Daniel
Alexander Kurtakov