My eclipse project come from my company versioning system (svn), and I have the same codebase as my colleagues. However, in a number of projects I have an exclamation mark like this .
In the "Problems View" I have tons of Project 'A' is missing required Java project: 'B'. Project A and B are both in eclipse, with no other errors than this.
Every project builds correctly. Sometimes, a generated class isn't properly located by eclipse so I get red lines everywhere in the file, but the maven build still yields 'SUCCESS'.
I've tried refreshing, cleaning, force updating, with no success. I don't know where to look, because everything works fine except the build path that I have no control over (it's all done automatically). pom.xml files are up to date. How do I fix this?
Related
I've got a grails project in STS. Recently an error has appeared at the project level ( the red [X] on the project) and it warns me everytime I run the project, but I can't see any files/directories showing errors and I've tried cleaning, refreshing dependencies, and even deleting the project and checking it out from SVN again. The project builds fine and runs without any actual errors as far as I can tell.
An additional tips on debugging this? It's basically an annoyance, but it's going to make it easier more me to miss real problems down the line...
My problem is resolved but I don't understand why it wasn't working.
Using: Grails 2.4.2, Groovy 2.3.7, Java 1.7, Eclipse- Indigo
I set my project up, and in the assets folder under grails-app I placed my static assets. I was also using twitter-bootstrap. The project would run, but nothing would be displayed from the assets folder. I did a Grails clean and got build path errors. in Eclipse right clicking the project name and going to Java Build Path and under the source tab there were links such as:
projectName/.link_to_grails_plugins/cache-1.1.7/src/java
or
projectName/.link_to_grails_plugin/asset-pipeline-1.8.11/grails-app/controllers etc
I deleted my target directory, and deleted all the links that were errors inside the Source tab. I restarted eclipse and refreshed, and voila it worked. The links came back, looked exactly the same but were now good apparently. I'm just not 100% sure why it worked though. The assets were in the right place, and never moved. Why did this work?
Eclipse doesn't parse BuildConfig.groovy or infer paths or dependencies - it gets all of that from Grails. You can force it to reconfigure the classpath by right-clicking on the project node in the tree on the left and selecting Grails Tools | Refresh Dependencies. That will cause Eclipse to run grails compile --non-interactive --refresh-dependencies and it gets classpath information from that.
When you restarted it must have determined that enough had been deleted that it needed to refresh itself, or it might just do that each time you restart.
Introduction
I have spend a lot of time to fix this bug
In our application we have a lot of generated code by cxf and jaxb which produces tons of warnings. We use the maven-build-helper plugin to add this code to our projects automatically.
By adding this enhancement, eclipse JDT enabled the possibility to set the javac -nowarn flag for specific source folders. Unluckily, by updating the maven project the flag gets lost. There are a few threads on SO where users got bugged by bug.
What I have tried so far
So i came up with a clever solution, javac has a nowarn flag. I set it to my maven-compiler-plugin and specified the directory. My maven build was fine, but my eclipse build wasn't. My research told me, that eclipse jdt does only use the maven-compiler-plugin source and target version. So my next step was to try to configure the EclipseCompiler, but this is not possible, because there is no possibility to add custom compiler Arguments in eclipse JDT.
Next Step. Inside of the .classpath file, eclipse JDT adds an ignore_optional_problems attribute for each ignored path. By updating the maven project inside of eclipse, this entry gets lost. So i started to write a maven "ignore-source-folder" plugin which should add the missing attribute. To run the plugin each time eclipse starts a build, i also created a m2e connector to refresh the .classpath file and everything should be fine.
By testing my plugin with my connector i realized, it works, but only 70% of the repetitions.
What happened?
Every time eclipse m2e/Jdt starts a new build, all classpath entries will be removed and populated again. When my maven plugin gets triggered by eclipse, a race condition starts.
So I started to analyze the code of jdt and m2e jdt. The ignore_optional_problems flag gets only once set manually inside of the patch which was provided to JDT and isn't stored somewhere else. By triggering a new build via m2e-jdt this information gets lost.
How to fix this problem
To fix this problem, some element has to be added or extended in jdt which contains all ignored folders. If a new build gets triggered and the classpath file gets newly generated by m2e-jdt this element should be checked for ignored paths. ClasspathEntryDescriptor seems to be a good place for it.
My problem
I checked out jdt and m2e jdt, but i have tons of errors inside of my IDE and i have no idea how to start. And even if I fix the code, I have no idea how to build and test it. I think my effort will be to high and we talk about 20 or 30 simple lines of code.
I am afraid if I add my results to the filed bug at eclipse, no one will care about it.
So, is there any developer able and willing to help me for this tiny job?
You need to "fix" the M2E's JDT project configurator. Probably somewhere in the m2e-core project. So, your change should obtain some kind of configuration flag from the project pom and create corresponding classpath entries for JDT.
I have a maven project on eclipse with jrebel plugin installed. Hot-deploy used to work perfectly last week but now only xhtml pages are hot-deploy. When a java class is changed it doesn't hot deploy.
What I noticed is when I changed a file and save eclipse will automatically build it. But the output folder file is not updated base on file stamp that's why jrebel doesn't pick it up. When I run maven-install it compiles everything and all the java classes are reloaded which is not efficient.
So the main problem is eclipse newly compiled classes don't go to output folder (project/target/classes), even though it's set in Build Path.
Any idea?
By default, the content of your local Maven repository is cached for a day. This can happen even for bad downloads (as I experienced). See https://stackoverflow.com/a/7421893/44089 for a short description of how to work around that.
After several minutes of testing, I found a warning on a jar file specifically guava being downloaded as dependency. I've delete in repo to be redownloaded and after that jrebel is working again.
So the problem is a corrupted jar that causes everything to be rebuild even if only a single file is changed. But the weird part is there's no corrupted file error.
I have added all common targets like (init, clean, getivy, etc) in ./common/common.xml and added:
<import file="${basedir}/common/common.xml"/>
in build.xml.
When I build the project, its working fine. But, When I open build.xml in Eclipse IDE, I see some "Red" marks underneath targets which have a dependency targets that are defined in common.xml. And when I do mouse over those Red marked targets, I see a message saying that:
Target init does not exist in this project.
To clarify, the common folder is added through svn:externals. Does this need extra configurations in Eclipse?
I have Eclipse Indigo Service Release 1 Build id: 20110916-0149 with ant 1.8.2 and the described problem with import seems to be fixed as Steve already mentioned. But the problem still exists for include and no answer seems to solve it for me. I searched the bugtracker shortly but don't have the time to be sure and test in the latest eclipse version and post a bug in the bugtracker.
Edit:
I had the problem with import again after refactoring the folder structure in the project and moving the buildfile. Although I started "Validate" on the project, the validation cached the old location and did'nt realize the move. I had to close the editor and the warning disappeared.
If your build.xml, and the common directory are at the same directory level then just try
<import file="common/common.xml" />
This works for me fine.
Use the include path ${basedir}/common/common.xml because . is probably the directory in which Eclipse is installed.
I found a post online here where someone found a workaround. You just need to make the file import not the first line in the ant build file. If you put it after a property declaration for instance the error goes away. This worked fine for me and eclipse is happy now.
The specific problem we had seemed to be because we
were importing common build.xml files into our project-specific build files, but the import was having problems when it is the first line in our
project-specific build file.
However, if I put a property task before the import, it seems to work fine. I am guessing this much force some initialization that wasn't occurring with only the <import>. I have no idea why this same issue doesn't happen in either command line with Ant 1.8, or with Eclipse using Ant 1.7.