I created new xerces bundle from jar. I can see two org.apache.xerces bundles now - one from orbit 2.9.0 and "my" 2.11.0. If I try to export product then only the version from orbit is exported
I tried to specify version in dependency for org.apache.xerces using properties, but it does not help, the entry is also marked as erroneous (how to see the reason?).
I am using
Eclipse for RCP and RAP Developers
Version: Luna Service Release 1 (4.4.1)
Build id: 20140925-1800
I missed qualifier! I need to put e.g. 2.11.0.201411051547 instead of simply 2.11.0. That is not really what I want- modifying product configuration after each plugin build, but it helps to force export of missed bundle.
Related
In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.
Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:
However, I am not able to reference that module in my module-info.java. I tried
require org.eclipse.swt.3.106.1.v20170926;
require org.eclipse.swt;
require swt;
None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and
jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d
says that the module descriptor can not be derived. Also see
Unable to derive module descriptor for auto generated module names in Java 9?
If I download a newer version of swt.jar from
http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip
I get following output that looks promising:
swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets
I also depend on org.eclipse.jface and could not find a seperate download for it.
=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?
Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.
requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'
or
requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar
but module-info.java does not seem to support such a syntax.
I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.
I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200
Edit
When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using
require org.eclipse.swt;
and having the Plug-in Dependencies in the Modulepath.
However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.
I created a min example at
https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin
and I filed a bug report at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089
Related questions:
How to use 3rd party library in Java9 module?
Unable to derive module descriptor for auto generated module names in Java 9?
Force Eclipse (Helios) to use a newer version of SWT at application runtime
JFace libraries stand-alone download (not picked from Eclipse plug-ins)
New Keywords in Java 9
What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.
Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.
This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:
Automatic-Module-Name: org.eclipse.swt
I've been setting up the workspace for IntelliJ's plugin development. There is one issue that I'm not able to solve.
I have two plugins: A and B. The B plugin depends on A. The A plugin is provided as an install-ready zip package (I don't have the code and I don't want to add it to my project).
In the manual, I met this page. I added jars from the A plugin (extracted from the zip file) to the SDK that is use when running B plugin. Unfortunately, when the sandbox is being bootstrapped, I get the following error:
Problems found loading plugins:
Plugin "B" was not loaded: required plugin "A" not installed.
Disable B
Open plugin manager
Does it mean that plugins from the SDK are not installed automatically?
I tried to install the A plugin in the sandbox but then I got a casting exception - two different class loaders were used.
Of course, I have appropriate dependency configuration in the B.plugin.xml file:
<depends>A</depends>
My question is how should I provide the A plugin to be able to develop the B plugin? Is it possible to develop the B plugin without A's sources?
In the jars that I added to the SDK's classpath, there is a package that contains the plugin.xml file for the A plugin. This plugin is also not listed on the list of plugins.
I'm sure that both plugins are configured properly because there are no problems when I install both of them in a standalone IntelliJ instance. Additionally, I don't have any compilation errors.
After couple more hours of debugging. The A plugin is marked as not installed because in the PluginManagerCore:loadDescriptorsFromClassPath method there are no appropriate jars URLs provided. It seems that BootstrapClassLoaderUtil doesn't include all of the entries configured in the SDK.
I tried to set -Didea.additional.classpath property, but I got the class cast exception again.
Finally, I have found the solution.
The B plugin consists of other B submodules:
B.submodule-1
B.submodule-2
B.submodule-3
One of these submodules had dependencies to the A's submodule. Something like this:
B:
| B.plugin-submodule
| B.submodule-1
| A.submodule1
| A.submodule2
| B.submodule-2
| B.submodule-3
Based on the gradle setup, IntelliJ resolved all of the dependencies for all submodules. Initially, I removed Gradle dependencies and set the JDK only for the plugin submodule. It was required to do so for the others (submodule-1/2/3).
My IDEA 10.5.2 hilights all guava (10.0.1) classes with error (no class found). But code is compilling correctly. I have this trouble only with guava jar's. Other jar's warks correctly.
I try to change guava version and jdk version (1.6, 1.7) and idea version but there is no result.
What am i doing wrong?
IntelliJ's indexes must not be seeing the class files, even if javac is. Depending on how your project is set up, your build process may have a different classpath than IntelliJ's indexes. At least as likely, though, is simply the presence of some corrupt entry in IntelliJ's indexes. Either way, do the following:
From the "Project Structure" dialog (in the File menu), go to the Libraries screen and ensure that the guava jar or its parent folder is listed in one of your libraries
In the same dialog's Modules screen, ensure that the above library is listed in your module.
Exit the dialog and click File -> Invalidate Caches.
Restart IntelliJ. This might take awhile.
With the information given, I can't be sure this is your problem, but it's always the steps I go through when a library mysteriously stops working (which happens more often than I'd like...).
[Answering this old question as I came across this situation even in Idea Community Edition 2019.3.1]
For me it had been due to a change in the version of the library in the build.gradle file, and the solution was to recreate the project in a fresh folder
(or maybe I could've deleted some .idea or cache folders).
It mainly depends on the version of the library in the build.gradle file.
In my case, at first, the version of the library referred to was an earlier version and everything worked fine.
compile group: 'com.google.guava', name: 'guava', version: 'r05'
Later, had to use a newer version of the library and some classes in this new version.
compile group: 'com.google.guava', name: 'guava', version: '23.5-jre'
Since build.gradle was updated, the project built fine as a gradle task.
IntelliJ hadn't got updated - though usually it does after a change in the gradle file.
Even after trying to mess around with File->Project Structure, and File->Invalidate Cache and Restart, etc... it hadn't worked, and finally recreating the project seemed to be a good workaround.
I have a RCP project where I cannot fix a NoClassDefFoundError: One plugin depends on another plugin. The plugin-dependencies are set in the manifest, packages exported, and there is no error at compile time. Both plugins are in the product dependencies and visible in the installation details of the product.
But when I run the application I get a java.lang.NoClassDefFoundError when the one plugin wants to use a class from the other plugin.
Any hints how to find the reason for this are greatly appreciated.
Thanks,
Michael
I found the problem: I created the plugin which could not be loaded from an existing Java project. And somehow I deleted the "." in the entry Bundle-classpath in the plugin manifest (the plugin has some jars which -> so lib/xyz.jar was in the Bundle-classpath entry but not the ".").
For the class-loader of the bundle the "." means to search for classes from the root path of the bundle (or something like that), so it could not find the classes. However, there were no errors in the IDE so it was hard to find.
Is the configuration for running the application correct i.e. all dependencies are also put in the running configuration?
This is a question already asked by someone:
How can an Eclipse plugin access the project directory?
The answer was good: using ResourcesPlugin.
But for some reason, under no circumstances will my Ganymede eclipse recognise the existence of org.eclipse.core.resources package which contains ResourcesPlugin.
Why is that?
This is usually something to do with the Manifest:
is the package imported (Import-Package), or the bundle required (Require-Bundle) in your plugin.
(sanity check) is the package exported by the source bundle (Export-Bundle).
If both of these check out, then I would look at the target platform. A typical base install for RCP only does not include the resources bundle.
(*) You might have specified a version constraint in the Manifest.MF for the dependency. And the available version is different. If so, remove the constraint or just click the Match in the Properties of the depedency
(*) Check your target platform and verify whether this org.eclipse.core.resources plugin exists
(*) If the error still persist, go to the Plug-ins tab in the launch configuration of your RCP. Check whether the o.e.c.resources is added. The Validate Plug-ins buttons should be helpful to determine any issues
Add the bundle org.eclipse.core.resources in your plugin dependencies. That should work just fine.