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?
Related
Using maven version 3.6.3 and JDK version "openjdk-17"
I've tried using Maven's dependencies so I could use the xstream library in my project. Following a guide I added com.thoughtworks.xstream to my pom.xml file:
I then tried to use xstream, but intellij couldn't resolve "XStream" even though it seems to work for JavaFX just fine. This code does not compile.
EDIT: I loaded a new project, where I used, what I believe to be, up to date versions. Maven 3.8.1, the latest intellij version, and everything else (JDK, openjfx) at version 17.0.2 yet when I try to use "XStream" in my project code (after reloading the maven project) it says "Cannot resolve symbol XStream"
Edit 2:
I added junit to the dependencies, it works. I add Gson to the dependencies. It doesn't work.
I figured out that in the "modules-info.java" file, "requires xstream" is needed. That is all
One of the following may solve your problem:
These are based on my previous experiences.
because may be auto import disabled. re Import maven project.(intellij: press Ctrl+Shift+A then actions - input "reload" find "Reload All Maven Projects").
in my experience, sometimes it does happen that the dependency is not fully received. remove xstream special version folder from .m2 (com->thoughtworks->xstream) and repeat step 1.
maybe repository not valid. check repository source in file settings.xml in .m2 (if exist) or replace to other source.
invalid cache and restart (intellij: file-> invalid caches/restart). This has solved my problem several times.
Your access to the site or repository may be closed. check network policy or use vpn (Poor probability)
I'm checking whether we'd be able to migrate from Ant to Gradle, but got confused right at the very beginning of these checks - Apache Netbeans 12 LTS (+ Gradle plugin from official repo) refuses to properly open Gradle projects that were created by a another Netbeans instance, which is a major pain.
I tried to open (in Netbeans) one of the Java library project examples from Gradle docs, only to find out the IDE immediately spews out errors (missing imports for tests) that are unjustified and offers a very limited amount of IDE integration - forget running specific tests, even debugging is all grayed out. Gradle and Netbeans also see different classpaths.
If I create a Gradle project inside Netbeans, everything works fine - no errors, Projects Tree shows an additional tree node, called "Configurations", like in the image below, I'm able to debug and everything just works.
However, even if I just copy/paste this project's directory to a different location, everything breaks after the project is reopened (I also get this issue, same thing happens for example projects found in Gradle docs).
What is going on here? Netbeans seems to know more about a project it created, than about projects that were created outside it or were just relocated. How do I force it to treat all Gradle projects equally (so that they work as expected)?
I used Gradle 7.0.1 and let the New Projects wizard "Initialize the Gradle wrapper" for the project created inside Netbeans 12 LTS. The setting to prefer existing wrappers is enabled in settings if relevant.
Enabling an "experimental" option in Gradle options, called Enable 'lazy' Source Group Initialization does help with simple projects that were created by Netbeans, so they open as expected.
But this does not work for Gradle projects that contain subprojects, such as the example project from Gradle docs:
The issue tracker for this Netbeans plugin has been quite active recently, mentioning issues like this, so perhaps there is hope.
At least part of the problem is that the LTS release of Netbeans (at the time of this writing) doesn't support gradle 7. The latest release, Netbeans 12.4, is the first version that supports gradle 7.
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.
I am in a bit of a jam.
I am working on upgrading our software to have Kettle 6.1. Specifically, we need the feature of S3FileOutput. Meanwhile, our application was already using the aws-sdk for other things.
So I am running into a problem: Pentaho Kettle requires version 1.0.something of aws-sdk. Our application, on the otherhand needs 1.9.6 of the aws-sdk.
To give more details, the feature of Kettle we require is in the pentaho-big-data-legacy plugin. Even if I upgrade to the latest version of Kettle, pentaho-big-data-legacy still uses the old version of the aws-sdk.
I've read a bit about plugins having special classloaders, so one option I was considering is that maybe I am not downloading the right dependency. However, when I tried downloading pentaho-big-data-plugin instead of pentaho-big-data-legacy, I got weird errors, so I stopped going down this path.
I was wondering if there is any way I could put the Kettle Libs in one folder, and my application libs in another folder, and then set some sort of a PENTAHO environment variable to pick up the libraries from the alternative folder.
Another option is if I could somehow set the pentaho classloader, but I don't know if this is possible.
What are my options for having 2 versions of the aws-sdk in my application, with regards to Kettle?
Maven can do much more than download dependencies.
The Maven Shade plugin can help with your current predicament. During a build, it can rename packages.
You would make a project that builds a "fat jar" (or "uber jar") with Pentaho Kettle and its version of the aws-sdk re-packaged as appropriate. That dependency would be handled before your project is built, so you are free to use whatever version of aws-sdk you like since there is no longer a conflict on package names.
I have a project (built from an AppFuse template) that requires Maven 2.2.1. So I upgraded to this (from 2.1.0) and set my path and my M2_HOME and MAVEN_HOME env variables.
Then I ran mvn eclipse:eclipseand imported the project into Eclipse (Galileo).
However, in the problems list for the project (and at the top of the pom.xml GUI editor) it says:
Unable to build project
'/export/people/clegg/data/Workspace/funcserve/pom.xml;
it requires Maven version 2.2.1
This persists whether I set Eclipse to use its Embedded Maven implementation, or the external 2.2.1 installation, in the Preferences -> Maven -> Installations dialog.
I've tried closing and reopening the project, reindexing the repository, cleaning the project, restarting the IDE, logging out and back in again, everything I can think of! But Eclipse still won't believe I have Maven 2.2.1.
I just did a plugin update so I have the latest version of Maven Integration for Eclipse -- 0.9.8.200905041414.
Does anyone know how to convince Eclipse I really do have the right version of Maven? It's like it's recorded the previous version somewhere else and won't pay any attention to my changes :-(
Eclipse allows you to specify an external Maven installation. But there's a catch. :(
Have a look at Windows > Preferences > Maven > Installations.
You will see a message like this:
Note: Embedded runtime is always used for dependency resolution, but does
not use global settings when it is used to launch Maven.
To learn more, visit the maven web page.
Translating to English, it means that Eclipse will continue to employ its internal Maven instance in order to perform some tasks.
When you "Run As > maven install" it will run your pom.xml script employing the external Maven instance you specified but when Eclipse performs some of its internal stuff, it will continue to use the embedded Maven instance, whatever version it is.
(edited)
As far as I know, when you install M2Eclipse you are implicitly defining which "internal Maven instance" you will have, which is exactly that one packaged by the plugin.
In the plugin configuration, you can add external Maven instances by telling where they are installed.
If you are using a recent m2eclipse version, you can try this too:
<prerequisites>
<maven>>=2.2.1</maven>
</prerequisites>
Notice the greater than in >=2.2.1. It works fine for me.
A common source of trouble (of this kind) is if you change global preferences and don't remember or know that you have enabled some project specific settings. At least it's a chance that the global setting is now set to use the external maven but the project setting is still set to 'embedded'.
M2Eclipse uses an embedded maven instance, not the maven instance you have installed on your system.
Have you tried switching workspaces?
You can still reference the same project in the new workspace. This would provide about as much of a reset as you can do in terms of eclipses internal settings.
Try creating your eclipse project with mvn project:m2eclipse or use the maven import option under import project.
Using m2eclipse, my fallback in these situations is to do Maven > Update Dependencies and then Maven > Update Project Configuration. The first is just me being supersticious, but the second will rewrite .project and .classpath.
As Pascal says about, m2eclipse can also be pointed at an external instance. I've done this in the past, though not at 2.2.1.
Dan
I got the same issue. Resolved it by restarting the system because every time you change the 'Path' in environment variables you should restart the system or else if would not pick the changes.