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.
Related
Just recently started using Eclipse and ran into an issue with exporting the plugin I'm working on. I tried to search but so far no luck - but if the answer is already here I'd be grateful if someone can point me to it.
I'm writing a n OSGi/Equinox plugin with Eclipse. The plugin is for a 3rd party system, which allows extensions: basically all jars placed in the application's plugin folder are automatically loaded into the application at startup. I have managed to put together my plugin, it's loading fine and it works.
The issue is that I rely on another plugin which is placed beside mine in the plugins folder. For obvious reasons I do not want to package that plugin into my plugin jar file. I have tried to add the dependency as an external archive, but this breaks the export: when I try to export my plugin project ant complains about missing dependencies and types. (If I actually include the other jar file in my plugin everything works, but obviously this is less then ideal.)
So: how do I set up my plugin project dependency, that it's a) an external dependency and b) doesn't need to be specified with a path or a variable - i.e. how do I tell my exporter to "don't worry, it will be there right beside you"?
Edit: Apparently there's an important detail I didn't mention. The external jar file I depend on is not an OSGi plugin, just a regular jar file with some classes in it. To the 3rd party system it seems all the same (all are under the plugins folder, all are loaded into the application), but for Eclipse the distinction seems important.
If you reference the other plug-in as a dependency in your plug-in's MANIFEST.MF the export should work without errors. The plug-in should be listed in the Require-Bundle list in the MANIFEST.MF.
You can do this in the MANIFEST.MF editor by adding to the 'Required Plug-ins' list on the 'Dependencies' tab of the editor.
Note: When referencing other plug-ins you must always use this method. Do not try adding the plug-in jar to the Java build path or anything like that.
If the jar you want to use is not an Eclipse plug-in you must should include it as part of the plug-in and list the jar in the Bundle-Classpath in the MANIFEST.MF. If you cannot do this you can reference an external jar in the Bundle-Classpath using something like:
Bundle-Classpath: .,external:$LIB_LOCATION$/lib.jar
. is the normal entry in for the plug-in code. external:$LIB_LOCATION$/lib.jar looks for lib.jar in a location defined by the environment variable LIB_LOCATION. This method can be difficult to get right.
In the end the solution to my specific problem was to add the external jar file as an Extra Classpath Entry on the build properties tab (this translated to a "jars.extra.classpath = .jar" entry in the build.properties file). I have also added the jar file to the project itself - after adding the extra class path entry that got changed into an external dependency automatically.
With these two changes I was able to successfully export my plugin, which didn't contain the external jar file, but was able to reference it when loaded into the 3rd party system.
I have been struggling a while now to try to reuse the RemoteService implementation from one GWT project into a new one.
Here's the big picture:
I have a working smartgwt-mobile project and we now decided we wanted a desktop version of the same project, using regular smart-gwt. The GUI of this new app will obviously be different but the server side code will be exactly the same.
I tried to just "borrow" the RemoteService interface, its async counterpart and the whole server package by either linking the package folders in the other project inside the new source structure (I am using Eclipse with GWT plugin) or by adding the borrowed code path as a filtered source folder to the build path, and while this satisfies the Eclipse dependency checker, the GWT compiler is unable to find the borrowed code suggesting I need to add "inherit" declarations in the module .gwt.xml file.
When I do this and recompile it now expects a second module .gwt.xml file in the root of the borrowed code which is not acceptable because it would affect the other project.
I have been reading up on the GWT module documentation but I fail to see how to implement such a scheme. It may actually be impossible to do what I am trying to achieve.
I would be willing, if that solves the problem, to create a third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects.
Does anybody have suggestions about how to tackle this issue?
I'l agree to "third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects"
Why because, I'm just already doing this. Yes that is Obviously an DAO project(DB layer) which has all my DB business logic methods there.
And its always better to maintain separate DAO layer to expose your data to services(ex.webservices).
So here's how I solved the issue.
The problem with linking to an existing GWT project source folders is that the GWT compiler always (at least that's what it looks like) expects to find a GWT module definition file (.gwt.xml). I have not been able to link in the source folders in such a way that the GWT compiler is happy, even though the Eclipse dependency resolver has no problem with it.
So I created a third project using the GWT Eclipse plugin. I unchecked the "Create Sample Code" option, so I ended up with an empty GWT project. I then selected 'Add' > 'New' > 'Other' > 'Google' > 'Module', entered a module name, e.g. 'myModule', a package name, e.g. 'com.myCompany.myModule' and clicked 'Finish'. The GWT New Module wizard created the package and a child package under it named 'com.myCompany.myModule.client' and I created 'com.myCompany.myModule.server' myself.
Now I copied the RemoteService and related classes (The implementation and Async version ), plus all the server side code the RemoteService code calls from the original project I wanted to borrow from and pasted it into the new project. Very soon I had all dependencies satisfied and I opened the Build Path dialog on the new Smart-GWT web app project and included the GWT RemoteService Module Project in the projects tab. Last thing to do was adding an inherit element to the .gwt.xml file:
<inherits name='com.myCompany.myModule.MyModule'/>
Voilá: That's all there is to it. If you select 'GWT Compile Project' It compiles and runs in dev mode without warnings.
I now still have to delete the shared code from the first project and inherit from the module, bat that is simply a repetition of what I already did.
In the end this was much less painful as I imagined it to be, so I recommend this approach.
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 a GWT project in eclipse with the following structure for the GWT module
com.foo.gwt -> Dashboard.gwt.xml
com.foo.gwt.client
com.foo.gwt.server
I have different packages com.bar.baz1, com.bar.baz2, etc. whose contents I want to include in client side code. All the files are GWT JAVA->JS conversion compatible.
The problem is that the <source> tag in Dashboard.gwt.xml, treats the path as relative to the directory of Dashboard.gwt.xml. So I cannot reference anything outside com.foo.gwt hierarchy.
So I created a new module MyNewModule.gwt.xml in com.bar and included baz1 and baz2 sub packages using relative paths in tag. Finally I made Dashboard.gwt.xml to inherit the new module.
This works fine when I compile the Dashboard module but fails when I compile MyNewModule.
That's because some classes in MyNewModule reference classes of Dashboard module.
I tried inheriting Dashboard module in MyNewModule. This creates a circular reference, but GWT doesn't complain about it. Everything works but I am not comfortable with the circular reference. I don't need MyNewModule, all I need is a way to include code from packages outside Dashboard module's hierarchy.
I am wondering why GWT does not allow absolute source paths.
Am I missing something here?
You dont need to compile each module separately. When you compile your com.foo.gwt project, GWT compiler will look for all dependencies in your com.foo.gwt.xml file and will compile ALL .java files both your com.foo and com.bar.baz. (and other libraries) to javascript.
As you said, its correct to put MyNewModule.gwt.xml in the com.bar.baz project and "inherit" it in your DashBoard.gwt.xml file. The part you are missing is to make a .jar file with MyNewModule project and put in war/WEB-INF/lib folder (just gwt.xml file and compiled java classes).
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.