I'm using Eclipse for some embedded development and recently is started to give me these errors every time I save a file or do a build. It's annoying but for the most part it doesn't seem to be causing any problems (It even still highlights warnings/errors int the source. What's going on here?
Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class
org.eclipse.cdt.managedbuilder.internal.scannerconfig.DefaultGnuWinScannerInfoCollector.
Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class
org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedGCCScannerInfoConsoleParser
It looks like the eclipse wiki FAQ says
The most likely reason is that an exception was thrown in the static initializer for a class declared by the offending plug-in. Check the .log file to see whether that indeed happened.
The Eclipse Platform loader will not load a plug-in when exceptions are thrown during the initialization of the Java classes that make up the plug-in.
Another common reason for this error is the lack of an appropriate constructor for the class being loaded. Most classes declared in extension points must have a public zero-argument constructor. Check the extension point documentation to see what constructor is required for the classes that you declare in an extension.
If the problem only occurs when deploying a packaged plug-in (i.e., when it is not started in a runtime workbench via PDE) it is usually a good idea to check the Bundle-ClassPath attribute in the MANIFEST.MF file.
The JAR file that contains the plug-in classes must be listed in the Bundle-ClassPath. Even if the plug-in's proper classes are all listed, class loading may still fail because a .class file may contain references to other classes that cannot be resolved at runtime. In this case, the missing classes need to be identified (usually by looking at the import statements of the problematic class) and the necessary entries need to be added to the Bundle-ClassPath. If additional JAR files are required, those JARs also need to be listed in the build.properties file so that they are included when the plug-in is packaged.
(See this thread as an illustration of that last point)
So, for instance, in this thread, for another issue back in eclipse3.0 time:
The plugin.xml file specifies "org.eclipse.core.runtime.compatablity" as a required plugin. However, I am using Eclipse Version 3.0.1 and should be using "org.eclipse.core.runtime_3.0.1".
Solution:
Replace the line in the Plugin.xml
<import plugin="org.eclipse.core.runtime.compatability"/>
with
<import plugin="org.eclipse.core.runtime"/>
VonC is right -- with a fair bit of detail on what might go wrong with class loading...
In this case, your arm.cross toolchain is referencing internal classes in CDT's managedbuild which aren't accessible. This is an incompatibility between your arm toolchain and CDT. You should file a bug with them on this error, first trying a newer version.
Related
I have a project that uses JPA QueryDSL. For that we use the com.mysema.maven:maven-apt-plugin to generate the so-called Q-classes (i.e. Java-code) in Maven phase generate-sources. The generated files are placed into directory <project_root>/target/generated-sources.
Subsequently, in phase process-sources we execute the org.codehaus.mojo:build-helper-maven-plugin to add that directory to the source path.
Finally that Java code then gets compiled in phase compile.
This setup works all fine when executing the build on the Maven command line.
When I try to run the build inside Eclipse I always get compile errors in some of the generated classes stating that it can not find one of the other generated classes that it refers to (some of the generated classes refer to other generated classes).
That class which is flagged as missing, however, does exist, but it seems as if the Eclipse compiler starts compiling the generated sources right away before the generation of all those files is complete, in this case before a class A is generated to which the generated class B refers to.
This is using the currently latest Eclipse version (2022-12) and I have defined M2E lifecycle mappings to execute these two plugins on configuration but not on incremental builds:
...
<execute>
<runOnConfiguration>true</runOnConfiguration>
<runOnIncremental>false</runOnIncremental>
</execute>
...
(I have also given it a try to run them on incremental builds but that didn't change anything.)
Any idea how to teach the Eclipse compiler to wait with compilation until ALL generated files are fully generated? Or any other idea why the Eclipse compiler apparently doesn't "see" files that have been generated?
Hope I could make myself clear...
With Eclipse >=v2022-09 (according to #howlger, I myself only tested it with v2022-12) the issue is fixed by specifying <m2e.apt.activation>jdt_apt</m2e.apt.activation> in the pom.xml's properties section.
Caveats:
for our multi-module project I had to select Maven --> Disable Workspace resolution for several modules that still showed errors despite that setting.
with these settings the build now succeeds and shows no more errors - albeit only after a few days of "burn-in" (c.f. my misc. comments). Initially those "class-not found" errors re-surfaced for a few days, but then for some reason disappeared. Maybe that disappearance has to do with my removal of the old "lifecycle-mappings" for said plugin from the pom.xml.
I'm in the early stages of creating a new Eclipse plug-in in Eclipse 2019-06. I created the plug-in using the "Hello World" wizard option and created a debug configuration that successfully launches a secondary workbench for testing. I can click on my new menu option and step into my new code.
I want to use a modified version of org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne, so I added the package to my project and edited NewTestCaseWizardPageOne. However, when I try to debug, the debugger asks for a source location. It seems to want to load the file from the local repository (.p2/pool/plugins/org.eclipse.jdt.junit_3.11.400.v20190510-0840.jar), rather than my edited version. Why is that?
There must be some kind of classpath problem, but don't versions of files in the project have precedence over those in the dependent plugins? I've looked at a number of similar questions (1, 2) and other sources, but I haven't yet found the answer. Please help.
Following Alexander Federov's suggestion, I converted my plugin into a fragment. This was fairly easy to do following the advice from this StackOverflow page. The main changes were:
Renamed plugin.xml to fragment.xml and changed the top level xml
element from plugin to fragment.
Added a Fragment-Host entry to MANIFEST.MF
The key advantage that this provided is discussed in an Eclipse Wiki
page:
... a fragment appears much the
same as a normal plug-in. A fragment can specify libraries,
extensions, and other files. When it is loaded by the platform loader,
a fragment is logically, but not physically, merged into the host
plug-in. The end result is exactly the same as if the fragment's
manifest were copied into the plug-in manifest, and all the files in
the fragment directory appear as if they were located in the plug-in's
install directory. Thus, a runtime library supplied by a fragment
appears on the classpath of its host plug-in. In fact, a Java class in
a fragment can be in the same package as a class in the host and will
even have access to package-visible methods on the host's classes.
The last part having to do with access to package-visible methods was what I needed. Thanks, Alexander!
I'd like to know how to configure the maven-bundle-plugin (backed by bnd) to completely ignore the classes contained within an embedded jar.
Background
I'm working in a controlled environment where the environment my code is running on is defined by a single company (including all the tools). The code is java and uses OSGi to define module dependencies.
Some of the provided modules contain what look like invalid class files, I can only assume that the system will 'correct' these class files before it tries to load them into any type of JVM. In any case these class files work when deployed onto the target system.
I'm trying to create a build system based on Maven that can produce packages the system understands and have hit a problem where these invalid class files are being read by BND (via apache-felix) which causes errors.
I'd like a way to have the jars that contain these class files on the class path of the bundle but where the contained .class files aren't read/processed by bnd. I could settle for simply ignoring the errors and continuing but can't find a way to do that either without felix aborting the entire build phase.
I just found the -failok directive, don't know why I didn't find it before. Adding <_failok>true</_failok> to the instructions allows me to continue working.
See instructions-ref
I am trying to extend a third-party Eclipse plug-in by using a fragment project. The major reason is that the third party plug-in contains classes having the default (package) modifier and I need to extend them.
Thus, my extensions class must be located in exactly the same package. I create a fragment project containing the same package and put my class into it. Everything works fine when I am using a runtime workspace.
However, if I try to deploy my fragment (e.g., deploying it into the dropins folder of my Eclipse distribution), I am not able to execute the code. Extensions and stuff like that work fine (e.g., I use extensions for a new Run Configuration. However, if I try to instantiate this run configuration I get an error message that the third-party root plug-in was unable to load the class to display my configuration tab group.
Any experience with this kind of problems?
Sorry, but that does not work. Unless the host bundle has been crafted specially for it, you cannot override a class in the host from a fragment. The reason is that resources - including classes - are retrieved from the host before any fragment.
See org.eclipse.osgi.baseadaptor.loader.ClasspathManager for the implementation..
Actually, this is the extension code I am using:
<extension point="org.eclipse.debug.ui.launchConfigurationTabGroups">
<launchConfigurationTabGroup
class="com.android.ide.eclipse.adt.internal.launch.jouleunit.AndroidJouleUnitTabGroup"
id="com.android.ide.eclipse.adt.jouleunit.AndroidJouleUnitLaunchConfigTabGroup"
type="com.android.ide.eclipse.adt.jouleunit.launchConfigurationType">
</launchConfigurationTabGroup>
Of course, there are further extensions definig the launch configuration type etc. but this is the one leading to the class which Eclipse can not find.
Actually I found the problem now for myself. The problem was a wrong configured build properties file which excluded the Java byte code from my fragment JAR. Very itchy, as the classes were in the JAR but in a wrong subdirectory.
I have troubles understanding what to specifically add to the classpath, or what this error means.
My setup is this in Netbeans:
Package
--> src
--> FooMainApplet.java
--> FooMainAppletMyJcomponent.java
The Jcomponent class simply extends jComponent in which I believe is valid, and has a few helper methods (i.e. getPreferredSize() and alike)
I can add this new component manually, with the getContainer().add() method however it is not visualized on the designer, even if I use the second .add() parameter and define the layout styles as the designer would normally.
When I try to add it as a component (i.e. dragging the .java file on the the form, or manually adding it as a .jar file in the pallette manager, or even placing it in what I assume are class path jar's) it comes up with the following error:
Cannot load component class <projectname>.<customcomponentsname> from JAR file: <some path to dist>/<mainprojectjar>.jar.
The class must be compiled and must be on the classpath of the project to which this form belongs.
And above it in the IDE log it complains about an unsupported major.minor versions in my custom component's class Unsupported major.minor version 51.0
I am sure this is related to me adding the .jar in dist/ rather than what I had done before (simple dragging of the .java file as I have read could work) however they both lead to it saying it is not compiled or in the class path, even though I do add the .jar in to the project's library section and that seems all I can do.
Do you know what the issue is, and how to work around this? Do I need to compile the custom component as a completely separate .jar (separate from my main applet class) in order to use it in the designer (even though it lets me select which class to use)?
My project is built each save, and still after a clean make it still issues this error as well.
I am using Netbeans 7 and JDK 1.7 I believe
Completing a clean and build should resolve the issue.