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:
Why does Eclipse RCP break projects with its new version? Was that considered a bug before? (I did not find a ticket)
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:
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?
Why does eclipse editor not show the problem if I only have a transitive dependency to javax.xml plugin? Also a possible bug?
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.
Related
I have an application that compiles a lot of reports at build time and fills them at user requests during run time.
I use the library version of jasperreports as dependency through Maven. I just increased the version number to 6.3.1. I was prepared for API changes and different behavior with the new version. However there is one thing I just can't seem to work out...
I use a utility package in some "text field"-elements in report designs that use (static) methods for stuff like formatting or validation. The package is in the same project and after compiling in the same .jar-file as the reports. Example:
<textFieldExpression><![CDATA[TemplateUtils.formatIban($P{iban})]]></textFieldExpression>
The package is also imported in the report:
<import value="de.company.app.utils.*"/>
The problem is that this package and other classes in my own packages are no longer recognized when trying to compile reports:
de.company.app.utils cannot be resolved
These packages are definitely on classpath of the project. Also, external libraries referenced as Maven dependencies (like Apache commons) are recognized without trouble and reports using them compile as usual. Only my own packages in the project are affected.
Even when trying to compile directly through the Eclipse plugin or a fresh installation of Jaspersoft Studio 6.4.3, compiling fails with the same error.
I've gone through the changelog and didn't find anything relating to this.
For some reasons outside my control the project I am working on uses ivy.xml for buildtime dependencies and we have a separate runtime.xml ivy file for use when running up a service in eclipse. This is done by created a new runtime configuration and then adding the runtime.xml via the Advanced option on the Classpath tab of the launcher.
This works fine and the application runs up without any problems. The one major annoyance, is that having added runtime.xml the classpath view of the launch configuration just displays Ivy and does not provide a tree structure view like you get in the Project Explorer view (see screenshot below). This makes it impossible to quickly view the resolved dependencies for the runtime configuration.
We are on eclipse Kepler and I appreciate it is an older version, but was wondering whether:
There is a workaround?
This may have been rectified in a later version?
This is the situation as best I can describe (I didn't create this project, so I can't say why it was done this way).
I have 3 projects:
SupportProject_A
SupportProject_B
MainProject which is dependent upon both support projects (in required projects in the build path).
SupportProject_A has SomeJar1.0.jar
SupportProject_B has SomeJar2.0.jar
The name spaces and class names are the same in both version of SomeJar, but the class definitions differ. This is causing havoc because eclipse is complaining that SomeClass.method does not exist, which it does in SomeJar2.0.jar, but not in the 1.0 version.
Is there a way, in MainProject to say, ignore SomeJar1.0.jar from SupportProject_A?
Use Dependency management system like Maven or Gradle (Gradle is my fav though). You get the plugin for both in eclipse. Once you figure out which one suits your requirement, find out which jar version is suitable for both the projects and add that to the build.gradle file along with the repository that has these versions. You should be able to setup the whole project with gradle and gradle takes care of the rest!! Good luck.
Eclipse used to build projects? It's so 2001.
But, anyway. There is two options:
1) Use one version of the library for every project.
2) Use maven.
My choice would be to use maven as relying on IDE to build your project is a bad practice.
I've used a 17 version of Guava for my library project and extracted it into the jar. Other project uses my library but it also has a much older version of Guava. When I try to run application, it ignores new Guava and causes errors like
java.lang.NoSuchMethodError: com.google.common.cache.CacheBuilder.maximumSize(J)Lcom/google/common/cache/CacheBuilder;
How to force my project to use a new Guava and application to use an old?
I am assuming that your project and applications are distinct entities.Also, by Project I assume that you are referring to an Eclipse/IntelliJ/Netbeans project
You would need to set the correct classpaths for the Project and your application separately.
If you are using the IDE to debug your project, your project would need to include the new JAR that you have downloaded. Each IDE has it's own mechanism for adding dependencies to the Project's classpath and hence you would want to refer to the documentation related to that IDE.
For your application you can launch it as java MyApp -cp "path to the old JAR". If you are packaging your application as a JAR, make sure you are packaging the older version of Guava.
Hope this helps.
Edit based on the discussion with the owner of the question
The query here is similar to this SO query. The right way to hence resolve this issue would be either install a Custom ClassLoader or use OSGi
I have a problem concerning target definitions in Eclipse. I want to use plugin version 1.0.0, which is in my target platform definition, while I have the plugin project in my workspace with version 1.0.2. For all other plugins in my target definition, everything works as expected (which I see because an error gets flagged if something's missing), but this specific one, Eclipse does not make available to my projects. Only the plugin version 1.0.2 is. The plugin is not set as a singleton.
Why is this and how can I resolve this problem?
I figured out that I can access the right version when I close the project that contains the wrong one - but this is awkward, is there another way?
It seems that it's actually not an eclipse-specific problem, it fails also when building on the command line through maven/tycho. Specifically, my target platform is the Juno Release. Are there plugins that, while part of a feature, are not made available to other bundles? I know the plugin is there, but neither tycho nor Eclipse want to make it available to me.
Maybe I should also say it fails at compile time.
While, as I said, there exist workarounds for the problem, I still would like to have a "nice" solution to this problem. You can check out the project together with the target definition at https://github.com/kutschkem/Jayes
You may also need to check out and build this project first:
git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git
After setting the target platform, try building something with Jayes 1.0.0 (which is in the target platform) instead of Jayes 1.0.2 (which is in your workspace). You can also try to build with maven, it doesn't work as well.
Known workarounds:
Close the Jayes 1.0.2 project. Then, eclipse lets you use Jayes 1.0.0
For running an (OSGi) application, you can choose which bundles are loaded. You can choose version 1.0.0 manually there
Using a product definition, you can access the same runtime configuration as for workaround 2
If someone finds a workaround for maven, I'd be happy to know about it.
Maybe you have set your plugin to be singleton, so there will only be one instance for the bundle with a specific id.
You can change this by remove the "singleton:=true" in your MANIFEST.MF.
Bundle-SymbolicName: org.eclipse.xxx; singleton:=true
Or, you could remove the 1.0.2 version plugin from the run configuration when start running. click run --> run configuration to open the run configuration dialgo, switch to 'plugins' tab, here you can select which of these plugins you want to use .
I think you have already tried the following, but a reload of the target platform might help.
Also, what does your feature.xml file specify for version of that plugin?