I am developing a Java project using Eclipse. The project uses another project called engine, which I have added in my project build-path. As I need to call a dabo class, called House, in one of my project class, named Window, I have used the following code as usual:
import ee.asus.kernel.House;
I got however the following error in compiling time:
Exception in thread "main" java.lang.Error: Unresolved compilation problems:
The import ee cannot be resolved
House cannot be resolved to a type
House cannot be resolved to a type
House cannot be resolved to a type
at main.ee.asus.GUI.FrameWindow.Window.<init>(Window.java:10)
at main.ee.asus.GUI.StartApplication.main(StartApplication.java:13)
It's worth to point out that my prject and the dabo project use the same directory/packages names. Does anyone have a clue where the error may be?
The error can't resolve the first part of the package name: ee. Are you sure the package starts with ee? I see your Window class package starts with main.ee, does your engine project start with the same package structure?
I sometimes get weird behaviour with missing class files etc. when Eclipse is out of sync with the filesystem.
You could try refreshing all of your projects and doing a full rebuild.
I have been experiencing the same problem. I have an app A1(tablet version app) calling another app A2(phone version app). Upon calling, I see the same error message:
java.lang.Error: Unresolved compilation problems:
The import xxxxx cannot be resolved
xxxx cannot be resolved to a type
xxxx cannot be resolved to a type
xxxx cannot be resolved to a type
After poking around for a while, I realized the problem was the A2 doesn't run on tablet at all. It's weird because the immediate previous version of A2 runs perfectly on the same tablet(I have been on board only for 1 month). So I decided there was something wrong in the build config.
Finally, I fixed the problem by changing the order of Java Build Path. Although I have no idea why it worked, hopefully this will shed some light on your problem.
Look for the House class in your second project, opens it and see what package it is in.
(line "package xxx.yyy.zzz;" at the beginning of the House.java file)
Then make sure your Window.java file (class main.ee.asus.GUI.FrameWindow.Window) does have the line "import xxx.yyy.zzz.House;" in it.
In my case it was a version conflict.
I'm using maven and updated many packages and bumped versions of many projects. Maybe the reactor built mixed something up, or the transitive dependencies weren't up-to-date, or it was a change in a project without a version increment. However, rebuilding that project explicitly via maven fixed the problem.
Edit: When I think about it, it might also have been a conflict between eclipse's auto-build and building via maven on the command line.
Related
Since a very long time I'm using STS (eclipse) to code on jenkins and jenkins-plugins.
But since I upgraded to the latest version (STS 3.8.1) I'm not able to do so anymore... The reason is an error I get when ever I import a jenkins-plugin project (maven based, e.g. https://github.com/jenkinsci/config-file-provider-plugin/):
Only a type can be imported. com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl resolves to a package
While the message is true about the fact that there is a package called the same as a class, this is the case for many many classes in the source of Jenkins. This is actually a convention, all resources belonging to a specific class have to be places in a package with the same name as the class.
Is there anything I can do to ignore this error?
its a bug in eclipse and hopefully fixed soon: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598
I am attempting to follow the Language and File Type tutorial for JetBrains IntelliJ
It worked, once. Now (whatever I do) I receive an assertion failure stating that it was expecting an instance of FileTypeFactory and got my SimpleFileTypeFactory
My public class SimpleFileTypeFactory extends com.intellij.openapi.fileTypes.FileTypeFactory so I'm not sure how to react to this ...
Caused by: java.lang.AssertionError: Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual: class bengie.idea.SimpleFileTypeFactory
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.assertClass(ExtensionPointImpl.java:408)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processAdapters(ExtensionPointImpl.java:242)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.getExtensions(ExtensionPointImpl.java:185)
... especially when Google has no matches for "Expected: class com.intellij.openapi.fileTypes.FileTypeFactory; Actual"
Has anyone resolved this sort of thing?
I was depending on a Maven module (actually, two of them) The rest of my project is built with Maven so it seemed logical and looked like it would work. I didn't remember the build seizing up when I added them, so I had forgotten about it. Removing the dependency, starting a debug session, uninstalling the plugin, rinse, repeat and I eventually stopped seeing error messages.
I've since stuffed the maven modules into a jar-with-dependencies and told the IntelliJ plugin module to load the resulting .jar No problems so far - Yay!
We have a package that ends with exception e.g.
package a.b.c.exception;
Our code base had no issues up till eclipse 3.3, however when we shifted to eclipse 3.4, it started giving errors related to this package:
"The package a.b.c.exception collides with a type"
When I refactor the package name to a.b.c.exceptions, there are no issues. Is this due to a bug in eclipse 3.4 or is there some setting to rectify this behavior?
It's because you have a class named exception (with a lower case "e") in the a.b.c package and a package named a.b.c.exception.
It causes a name collision because if you have the code a.b.c.exception.doSomething(); - does that mean you want to call the static doSomething() method in the a.b.c.exception class? Or does it mean there's a class called a.b.c.exception.doSomething that you're trying to invoke the constructor of?
Stick with the Java naming conventions - packages all lowercase, classes starting with an uppercase and camel-case after - and you'll never see this problem.
==========EDIT==========
This is the only legitimate reason this error should be showing up...
It doesn't have to be in your project directly, it could be in another project or library that your project depends on. This should show you any occurrences of the class anywhere on the build path or your project : Hit the Flashlight looking button in the Eclipse toolbar -> Choose 'Java Search' -> enter a.b.c.exception in search field -> select 'Case sensitive' -> select 'Type' in 'Search For' -> make sure all options are selected for 'Search In'.
Are you using any tools that generate classes? Could they be putting them into the build directory of your project? When you see the error, if you go to the project's build directory, and go down into the a/b/c/ directory do you see a .class file for 'exception'?
Of course Eclipse in general could have a bug (though I'd expect there would be a bug report in Eclipse 3.4 and you'd be able to find more complaints if it was...), your Eclipse install could be broken in some way (Can anyone else open your project in Eclipse 3.4? Could you do a clean Eclipse 3.4 install in another directory? Does the error appear there?), or your project could be messed up in some way (Create a new project with no dependencies other than the JDK, create the a.b.c.exception package in your new project, create a class in your project to import a.b.c.exception.*; and see if the error occurs.).
In Java you can not have a class name that is the same as a package name.
That means the JDT package must have enforced that rule only in 3.4
See bug 63668 for instance.
As Nate comments:
A class named Exception won't prevent you from creating package exception.
Case matters.
Also remember the full name of a class includes the package it's in.
So a.b.SomeClass (class name) is different from x.y.SomeClass (package name).
There would be no name collision here.
The class name and the package name have to match in both case and package to cause this error.
See his more accurate answer.
I encountered a similar problem in a huge code base that I inherited. It turns out that the clash was caused by an partially qualified class name in a JavaDoc link.
To paraphrase, Eclipse was telling me that I had a package/type clash for a.b.c.d. when compiling a.b.c.d.London. Doing a java search on the code for a.b.c.d revealed that Eclipse thought that a JavaDoc comment in a.b.c.Paris was a match. The JavaDoc comment contained {# link d.NewYork}. When I changed the it to read {#link a.b.c.d.NewYork} the compilation error was resolved.
It should also be noted that NewYork was not imported into the Paris class as it only appeared in the JavaDoc comment. This also made it un-resolved in its abbreviated form and clicking on the link in the comment did not work. Making it an absolute reference also makes the JavaDoc link work.
I know this will sound silly, and possibly too simple to be true, but I solved this exact same error message by:
Deleting the entire line of the package name causing the error message.
Saving the .java file(this triggers a new error on the same line stating "The declared package "" does not match the expected package"), which it should do.
Re-typing the original package name onto the same line.
Saving the .java file.
Could not tell you why this worked, but it did, and Eclipse stopped throwing a tantrum on the spot.
Safe typing and speedy coding.
-Goodge
I changed one of the compilation option in eclipse and the problem disappeared.
Under workspace properties:
Java Compiler -> Errors/Warnings ->
Change 'Unused import' from 'Warning' to 'Ignore'.
If you have a class Foo, you cannot have a package that ends with Foo, such as com.my.Foo.
Also if you are using maven style, you have resources in your project under something like src/main/resources
The folders in your resources also have a package style and there, also, you cannot have a folder that contains the name of your class.
you will definitely encounter this problem when developing a Jenkins plugin according to the recommended conventions.
if you follow the Jenkins conventions, and you create a builder in a class named MyBuilder in package x.y then you are also supposed to place your .jelly in a resource folder named x.y.MyBuilder. This will result in the above problem.
However, if you name your resource folder x.y.myBuilder (notice lower case 'm' in myBuilder), unlike the recommended convention, the plugin will still work as you intended
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
I've just created a project on Eclipse and imported some source files (existing project). But I can't compile it ! Ok, the project has got several source files, so I wanted to compile only the Main.java file (with eclipse not in the command line, in the command line it worked!) but all what I get is this error :
http://www.screencast.com/users/Amokrane/folders/Jing/media/82d772dd-10cd-4552-b1d0-3cf18bf39f13
As you can see the Main.java file is straighforward, just a hello world !
What's the matter ?
Thanks
"Unresolved compilation problem" means that the class hasn't compiled successfully. Eclipse will still let you run code that doesn't compile, but any of the specific bits which don't compile will throw this error. Look in the "Problems" tab to see what's wrong.
From the look of the Package Explorer view, every single class has a problem... perhaps the file location doesn't match the package declaration? That would match the position of the pink box just to the right of the vertical scrollbar for the class - it suggests that the error is right at the top of the file, which is where the package declaration would be.
You have a compilation error at the top of your Main.java file, just out of sight in the screenshot. Probably an unresolvable import or a wrong/missing package declaration.
It is simple in my case that the imported project needs 32 bit jre to run but cannot be compiled in the same. In IDE, if you click run, it will try to compile and run the project in single shot so fails due to 32 bit jre for compilation with the above reported error.
So i used 64 bit compiler and started to run and got compiled successfully but thrown error that needs 34 bit jre for some of the SWT used in the project. Again i changed the 32 bit jre and run the project, it is gone ! THE ERROR IS GONE NOW !
You can get the error "Exception in thread "main"
java.lang.Error: Unresolved compilation problem:" if your public class name differs from your file name.
example:
File Name:
ServiceRequest.java
Inside file, class is named differently; like
public class Service