Eclipse plugin - wrong jar used on runtime - eclipse

I have a serious probleam with my Eclipse Plugin..
My plugin depends on another two plugins. All of theese plugins (including my plugin) use Mozilla Rhino engine - two of them use js.jar (version 1.4). But my plugin uses new version, which is not released yet and is packed in MyRhino.jar.
While developing, everything goes fine - code completion offers me classes and methods from my special version of rhino, no errors etc.
But when I run my plugin, a different version of Rhino is used and I get runtime exceptions like ClassNotFoundException and so on.
How am I supposed to tell eclipse to use the same jar in runtime as in development time?
When I was developing plugins on NetBeans, the solution was simple - wrapping the jar in a separate module, set which packages to export and declare dependency on this new module..
I found simmilar solution in Eclipse, however it did not work for me - although I declared a dependency on the wrapper plugin, the packages and classes were not available even in development time.
I've spent hours with this probleam and not solved it, so and help is appreciated. Thanks everyone.

Make sure your dependencies are correct. If your code depends on new version of library, then you need to indicate that in your MANIFEST.MF. E.g. if you require bundle org.mozilla.rhino, specify minimum version you need:
Require-Bundle: org.mozilla.rhino;bundle-version="1.5.0"
Your MyRhino.jar will need to specify correct version (e.g. 1.5.0), even though it is not released yet:
Bundle-Version: 1.5.0.qualifier
(If MyRhino.jar isn't converted to plugin yet, you need to do that manually: you can simply craete new plugin project using existing JAR in Eclipse)
Alternativaly, you can wrap MyRhino.jar into your plugin, and remove dependencies on other plugins. To do this, use Bundle-ClassPath (see http://www.aqute.biz/Blog/2007-02-19 for details). If you put your MyRhino.jar directly into your plugin, then Bundle-ClassPath should be:
Bundle-ClassPath: .,MyRhino.jar

Finally I've solved it..
It's simple to create the wrapper plugin form existing jar by the new project wizard in eclipse.. But the catch is that the wizard does not include the jar in bundle classpath (as I expected). Prety confusing (at least for me) that the wizard does only half of the job for you :/
After inserting the jar in the wrapper plugin bundle classpath, everytning works.
Thanks Peter for your answear anyway :)

Related

NoClassDefFoundError: org/eclipse/search/ui/text/TextSearchQueryProvider

I am writing a plugin for eclipse. When calling TextSearchQueryProvider sqProvider = TextSearchQueryProvider.getPreferred();, I get a NoClassDefFoundError.
The funny thing is, I only get this on the exported jar-plugin, not while debugging the plugin. I figured, it might be related to exporting the org.eclipse.search-plugin, but that plugin is so basic, that eclipse doesn't run without it anyway. So I guess the plugin should be there.
I am running eclipse photon (4.8.0).
Some more clarifications:
I have specified org.eclipse.search as dependency in MANIFEST.MF:
Require-Bundle: javax.inject,
org.eclipse.search;bundle-version="3.0.0";visibility:=reexport,
....
I have imported org.eclipse.search.ui.text.TextSearchQueryProvider
Do I need to do anything else, that I am not aware of?
Addition:
The plug-in related views did not show any obvious problems.
Specifically, the 'org.eclipse.search'-dependency is being satisfied by the version '3.11.200.v20180503-1856', which to me implies, that the plugin has been successfully linked?
The problem vanished, after I exported the plug-in with another version postfix.
I had originally called the postfix "beta". After giving it a new postfix with date,
the dependency tree seems to work correctly. It might be that the original package was bad and misconfigured in the MANIFEST, and only after reexporting with a different name, the pacakge dependencies were reevaluated corrrectly.

Define a Java 9 multi-moduled project in Eclipse

I'm trying out Java 9 Jigsaw module system (no module experience yet) and would like to use it for capsuling the classes within my project, but it's confusing.
According to this article it should be possible to have multiple modules within ONE project. I made a new project in Eclipse Oxygen (Java 9 is supported) with the same structure as shown in the article. But Eclipse keeps telling me that I must not have more than one module-info.java in a project.
I really don't know how to tell Eclipse that it should use the "multi-module-mode". And I really would appreciate not having to create a new project for every single module.
This works:
This not:
But according to this article something like that should work:
And how about deployment of a modularized project with Eclipse? There is nothing to see about the new jmod extension. Do I still export it as a runnable JAR file like before?
Notice that my questions refer to working with the IDE (no command line, I mean with an IDE that should be possible, right?) Thank you for enlightening me.
Currently, Eclipse requires you to create a separate project for each module (e. g. because each module has its own Java Build Path).
To understand this design decision, consider that Java modules correspond to OSGi bundles / Eclipse plug-ins and it has always been to have a separate project for each bundle/plug-in. If you come from the Maven world, you would probably expect a deeper folder structure instead. But modules are self-contained and combining several modules into one project would only add an additional folder level without meaning. However, Eclipse supports nested projects and so-called working sets if you need an additional folder level.
Exporting modules as images is planned for Eclipse 2019-03 (4.11), on March 20, 2019 (see Eclipse bug 518445). Exporting modules as JARs that can be used on the modulepath (-m) already works (see my video).
I don't know if this question is still open for an answer, but you can solve this problem by simply removing all source folders on the build path. At least this works for Eclipse 2021-12 version.
As you can see this is a demo project from the Official Gradle Guide Book and it has multiple modules. Each module has its own module-info.java.
project structure in IntelliJ IDEA
If I open this project in Eclipse it will give me the 'duplicated entries on module-info.java' error.
Eclipse shows the error
But if I delete all the source folders on the build path, the error is gone and the project can be built and run without problem.
project properties: Java build path
The only problem is that you have to build the project with Gradle so that it will produce the .jar of each module and you have to include them in the libraries later.
include all the .jar in libraries
I think this is probably the same solution mentioned by howlger above.

Can I update an Eclipse plugin project, which is simply a wrapper around a jar?

Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)

Regarding 'singleton:=true' in Manifest file

I have a plugin which at present doesn't have any extension points (neither does it extend any other plugin). To resolve a certain issue I have to create an extension-point for this plugin and an appropriate extension somewhere else.
When doing this eclipse forced me to set singleton:=true in the Manifest file. I know the reason why this parameter has to be set, but I wanted to know if there are any implications on the functioning of the plugin within the product by introducing this parameter.
Thank you.
"singleton:=true" means that bundle only have one version could exist in the OSGi runtime.
Eclipse automatically adds the flag due to you provide an extension point in your bundle. If there are two version of your bundles providing the same extension point(have the same identity, might different attributes or elements) would make things mess.
From the Book Eclipse plugin Development by Dr Alex Blewitt:
The clause
singleton:=true
is an OSGi directive, which means that only one version of this plug-in can be installed in Eclipse at one time.
For plug-ins which add dependencies to the UI, there is a restriction that they must be singletons. (This constraint is one of the main reasons why installing a new plug-requires the IDE to restart.)

Does Eclipse do a binary-compatibility-check of jars as they are added to a project?

While I was singing the praises of Maven's dependency management, an Eclipse user told me (an IntelliJ user) they don't need stuff like that because any time they add a jar to a project Eclipse will test it's binary compatibility against other jars in the project.
Is this true? Is this Eclipse itself or a plugin?
Is there similar functionality available in IntelliJ/Netbeans?
Thanks.
I'm not aware of such a thing in neither Eclipse nor in Maven (you'd need something like the maven-clirr-plugin to do something approaching).
I just did the following:
Install Eclipse
Create new Project
Add a library that is missing dependencies.
Create a class that does something like System.out.println(com.library.AClass.class);
Note that Eclipse does not complain.
Run it and get java.lang.NoClassDefFoundError when the class is loaded.
This tells me dependency checks don't (always) happen.