I have a plugin that used to work with Eclipse Indigo, Kepler,Luna and Mars (4.5). It supports the Frege programming language (http://www.frege-lang.org/fregide/). It is based on the IMP framework, which is, unfortunately, not maintained anymore (and I don't have the source code).
Tonight I checked for updates, and it found Eclipse 4.5.1.
After updating, eclipse had a fancy new splash screen that says "MARS.1".
Yet it can't initialize the plugin anymore!
In the Error Log, I get the message:
Plug-in "frege.ide" was unable to instantiate class "frege.imp.builders.FregeBuilder".
and the stack trace seems to indicate that some method has vanished from the Eclipse API:
java.lang.NoSuchMethodError: org.eclipse.ui.internal.registry.FileEditorMapping.setDefaultEditor(Lorg/eclipse/ui/internal/registry/EditorDescriptor;)V
at org.eclipse.imp.language.LanguageRegistry.addUniversalEditorMappings(LanguageRegistry.java:393)
at org.eclipse.imp.language.LanguageRegistry.initializeRegistryAsNeeded(LanguageRegistry.java:268)
at org.eclipse.imp.language.LanguageRegistry.findLanguage(LanguageRegistry.java:206)
at frege.imp.builders.FregeBuilderBase.<clinit> (FregeBuilderBase.java:53)
...
Here are my questions:
Does anybody know why this method is gone?
How can I restrict installation of my plugin to LUNA, KEPLER and INDIGO only?
Would it be possible to supply a fake setDefaultEditor method that does whatever must be done now to register the Editor for the plugin?
The setDefaultEditor method does still exist in FileEditorMapping but it now takes an IEditorDescriptor argument instead of EditorDescriptor. This will cause the NoSuchMethodError. Since this class is an internal class and therefore not part of the API this is a valid change.
According to the IMP Wiki the IMP project has moved to a github project, you may be able to get up to date code from there (or at least get the source).
Related
The org.eclipse.swt.widgets.Monitor class is supposed to have an instance method called getZoom, which should return the zoom factor set on the particular monitor. It is documented here (after clicking on "Monitor"):
https://help.eclipse.org/2021-03/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/widgets/package-summary.html
However, when trying to compile the following code...
Monitor monitor = Display.getDefault().getPrimaryMonitor();
int zoom = monitor.getZoom();
..., I get an error saying:
java: cannot find symbol
symbol: method getZoom()
location: variable monitor of type org.eclipse.swt.widgets.Monitor
The method is documented to exist since SWT version 3.107, and I'm using version 4.6.1. All other methods of the Monitor class work as expected.
What am I missing here?
(If there is further information needed to answer this question, please feel free to ask.)
SWT versions do not match Eclipse versions. 4.6.1 is your Eclipse version (Eclipse Neon), this contains SWT version 3.105.1 which is too old.
SWT 3.107 was first included in Eclipse 4.8 (Eclipse Photon). I think later versions extend the platforms on which zoom is supported so you should try to move to the current Eclipse 2021-03 (2021-06 shortly)
I have a Codename One project on Netbeans using their plugin.
Is there a way to make it work? I enabled it in project's settings and still doesn't show in final jar.
The annotations are in the libraries of the project. and I can see it being done in the output:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.netbeans.modules.openide.util.ServiceProviderProcessor' less than -source '1.8'
I used instructions here: https://netbeans.org/kb/docs/java/annotations-lombok.html
Update:
I thought it was clear but seems it's not. All this is using Netbean's Lookup. Let's say I have one jar as project dependency with one interface in it, let's say ITest. Also a class implementing the interface, for example:
#ServiceProvider(service=ITest.class)
public class Test implements ITest{
..
}
So in the Codenamone Project I call it like this:
Lookup.getDefault().lookupAll(ITest.class);
But it come up empty. I know the system works as it does in other projects, just porting it to Codename one. Seems like it is not seeing the annotations in the dependencies.
I don't know if that will work and I'm pretty curious about it myself. Make sure you created a Java 8 version of the project and you are running on top of Java 8 to get started.
In the past things like this were done using bytecode manipulation e.g. see this code from the work done by Steve.
I'm having the following situation:
I want to extend the functionality of a given plugin A (I have it's source code and start it by running the project as an Eclipse Application which opens a new Eclipse IDE which provides the plugins functionality) with an plugin B I am writing.
My plugin does run when I run it as a Java Application. Let's assume it just prints Hello World in the console. What I want is that I can call the function which does that from plugin A.
What I did:
I added my plugin B to plugin As Required Plugin-Ins.
I create an instance of the class which implements the Hello World-print and call the function inside a method of plugin A (I also tried to make the method static and call it without creating an instance which resulted in exactly the same errors).
I created an Extension Point in plugin B and added it as an Extension in plugin A. I just set the ID and name in the Extension Point.
What happens:
When the instance of the class in plugin B should be created, the program crashes with this error:
java.lang.NoClassDefFoundError: de/name_of/plugin_b/package/ClassName
[...]
Caused by: java.lang.ClassNotFoundException: de.name_of.plugin_b.package.ClassName cannot be found by de.name_of.plugin_a.package_1.0.0.qualifier
I guess I'm missing something imporant - can someone help me out on what it is?
Edit 2:
I've just read that I have to add "." to the classpath. Seems like this solved the issue! Thanks for making me dig deeper into the manifest, greg!
I do get a different error now tho, which also seems to be connected to me making mistakes when creating the plugin as I do not get this error when I run plugin B as a Java Application.
java.lang.NoSuchMethodError: org.apache.lucene.store.FSDirectory.open(Ljava/nio/file/Path;)Lorg/apache/lucene/store/FSDirectory;
The problem is, tho, that this method does exists (see lucene API here).
As seen in the manifest, I added the lucene-jars to the dependencies of plugin B.
You need to include every package that other plugins use in the Export-Package section of your plugin. In the MANIFEST.MF editor this is on the 'Runtime' tab in the 'Exported Packages' section.
You don't need an extension point to make this work.
I'm building an optimization program using Optaplanner 6.2.0.CR4, and I'm running into reflection issues with the ReflectionPropertyAcessor class, line 63: return readMethod.invoke(bean) and the other invoke methods in this class. Debugging the code, I'm usually able to "Step-into" the code into whatever of my classes it's calling, but Eclipse throws an error every time it reaches the end of whatever method is being called. This results in Method.invoke(Object, Object) line not available, DelegatingMethodAccesorImpl.invoke(Object, Object[]) line not available, GeneratedMethodAccessor5.invoke(Object, Object[]) line not available and then a screen asking me to change the attached source.
I'm running JRE 1.8, and I have the source code for Optaplanner imported into Eclipse as its own Maven project, with my code as its own separate Java project for now. I'm pretty new to using Maven and build tools in general. Could this error be a result of bad dependencies, classpath, etc? Is there a better way to set up my project? I'm in the process of moving my code into a Maven project also.
What stacktrace are you getting in a normal run?
The call readMethod.invoke(bean) can fail if bean isn't an instance of the class for which the readMethod applies. If that's the case, I'd be interested in seeing the code, because optaplanner might be able to detect that fail-fast with a helpful error message.
Debugging won't work because Method.invoke is probably a native implementation (C instead of Java) in the JDK.
I am trying to be able to step through the code of a Hudson plugin called SVNPublisher. I checked out the code for SVNPublisher, used Netbeans to open the project, and clicked "Debug Main project". This results in a Firefox window opening address http://localhost:8080 which shows the Hudson main page. Clicking the "New Job" link results in an error page:
HTTP ERROR: 500
jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: <j:forEach> hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
RequestURI=/newJob
Caused by:
org.apache.commons.jelly.JellyTagException: jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:713)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
...
I am very new to Hudson and not very experienced with Java so I'm pretty much clueless on the meaning of this error.
Can anyone help?
I know this thread is v. old but I have just had this issues and wanted to help anyone else who has is.
I found I got this issue when I had a DescriptorImpl in a class (this is a sub-class of the main class). In my case this is ResourceAxis contains DescriptorImpl.
I started getting this issue when I renamed DescriptorImpl to ResourceDescriptorImpl. Then I started getting the following error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl.<init>(ResourceAxis.java:94)
This propted me to change ResourceDescriptorImpl back to DescriptorImpl - as it was complaining about DiscriptorImpl. At that point I got this error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl.<init>(ResourceAxis.java:94)
This one is complaining about ResourceDescriptorImpl. I realised I was not doing a Clean build each time and that the old compiled code might be causing issues (as I only change one class, so the other may not be re-compiled). If you see this issue try doing a clean build and see if that solves your issue.
Hope this helps.
I'm running into the same issue and unfortunately I haven't been able to resolve it yet either. As VonC mentioned it may have to do with a change in how generics are used between 1.5 and 1.6, this is problemaitc since even if you install a 1.5 version hudson requires 1.6 to build and run via hpi:run.
What I have noticed is that if you install hudson locally (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson#MeetHudson-TestDrive) you can use a maven install command to generate an .hpi file of the plugin and install that. I don't get the same error when I do that which makes me think it could be an issue with the hpi:run goal. That should at least let you test any changes you need to make.
Coincidentally I'm the author of that SVN Publish plugin if there are any questions you have. I haven't made any changes recently, but I found this thread because I have some in the works and ran into this issue ;)
Thanks,
Brent