1

I updated an Eclipse RCP Project from Eclipse 2019-12 to 2020-03. After the update I get build errors on export, like the following: "The package javax.xml.parsers is accessible from more than one module: , java.xml".

I am using Java 11, no module-info.java file, the Eclipse 3 Compatibility Layer and the eclipse product export wizard in my project.

The error message basically is clear to me. It detects some class twice on classpath, which is not allowed. Once the class is provided by JDK module "java.xml". The second copy comes from javax.xml osgi bundle. My problem is that both of the packages can not be removed. The JDK module has a lot of dependent JDK modules that are actively used in code and I don't think that they can be supplemented by some libraries. The OSGI bundle is used by a lot of very basic eclipse bundles. So it can also not be removed.

So I have two questions:

  1. Why does Eclipse RCP break projects with its new version? Was that considered a bug before? (I did not find a ticket)
  2. How can I get my project to run again without really big changes?

Edit 1: Added reproducible example: https://workupload.com/file/wKUZTXJXsR9

Edit 2: See also Eclipse Bug Ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=562761

I created a minimum example. One can see the problem by exporting the product via wizard. I used DocumentBuilderFactory from javax.xml in Application.java to trigger the problem. I found out a few things:

  • A plugin dependency to org.eclipse.help.ui is needed to trigger the problem. Although also other plugins have dependencies to javax.xml plugin.
  • Eclipse tells you the problem in Editor if I you add a direct dependency to javax.xml plugin. But we have only a transitive dependency to it and therefor get no hint.

That raises some new questions:

  1. It seems that org.eclipse.help.ui plugin causes the problem, but we need it in our application. Is this a possible bug? Are there alternatives?
  2. Why does eclipse editor not show the problem if I only have a transitive dependency to javax.xml plugin? Also a possible bug?
Stefan
  • 157
  • 1
  • 7
  • This seems strange because Eclipse itself is just an RCP and obviously builds correctly with the javax.xml plugin included. How exactly are you building your RCP? – greg-449 Mar 22 '20 at 19:03
  • We use a product file and the product export wizard. Eclipse IDE uses Tycho i think. – Stefan Mar 22 '20 at 19:26
  • The Export Wizard has been in maintainance mode for a long time now and certainly doesn't work properly in some circumstances. Maven + Tycho is the only supported build method. – greg-449 Mar 22 '20 at 19:58
  • This is a compile error probably of one of your plug-ins. It's a limitation of Java 9 and higher given by the Java Language Specification, not by Eclipse. I guess that not upgrading Eclipse but using Java 11 instead of Java 8 in one of your plug-ins is what led to this issue. But that's just guessing, since a [reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) is missing. – howlger Mar 22 '20 at 22:38
  • We are using Java 11 now for some time, we did not update lately. You are right, I need to provide a minimum reproducible example. I will try to provide one in the next days. – Stefan Mar 23 '20 at 08:49
  • I added a minimum reproducible example now. – Stefan Mar 26 '20 at 21:18

1 Answers1

-1

I found a workaround for this problem: When using a target definition (*.target file) instead of the Running Platform (automatic target definition of the Eclipse IDE) the error does simply not occur! I don't know exactly what the difference is between these two targets, since they both contain the "javax.xml" bundle. But when using the target file the "javax.xml" bundle is not added to the product file when automatically adding the dependencies and it does not complain later on that this bundle is needed "javax.xml". Somehow when using the target file the "javax.xml" is simply not needed and then no error occurs.

I think there is a bug in Eclipse RCP, that causes this problem when using the Running Platform. But I suggest using a target definition file anyways, since this brings a lot of other advantages.

Stefan
  • 157
  • 1
  • 7