Common targets are not recognized by Eclipse - eclipse

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.

Related

Scala IDE 4.0.0 thinks there's errors in an out-of-the-box Play Framework 2.3.7 program

I've created a Play Framework program via Typesafe Activator (so it follows the template exactly).
I used sbteclipse-plugin version 3.0.0 to create an Eclipse project and imported that into Scala IDE 4.0.0. These are all the latest versions at the time of writing.
The Scala IDE definitely seems to support the Play Framework. It has syntax highlighting for the custom formats, including the routing file and templates. Yet, it doesn't seem to be able to find the views from the controllers. In particular, the call to views.html.index triggers an error: "object index is not a member of package views.html".
I tried enabling refreshing using native hooks or pooling as detailed here, but it had no affect.
I should note that while the code has been compiled in the command line (with activator ~run), it hasn't been compiled in Scala IDE, since I don't know how to (it doesn't seem to be documented anywhere).
What can I do to get rid of these false errors?
EDIT: After running activator clean ~run, I have another error: The project cannot be built until build path errors are resolved. There's no further details on what these build path errors are.
Update: Just upgrade to sbteclipse version 5.1.0 and everything should work out of the box. Also make sure you follow the Play documentation on how to set up Eclipse/ScalaIDE.
This is a known bug in sbteclipse, which probably will be fixed soon.
For now, you can add the following line to your build.sbt:
EclipseKeys.createSrc := EclipseCreateSrc.All
Kill the SBT console and run sbt eclipse again. That should add the following line to the .classpath file within your project folder as a workaround:
<classpathentry kind="src" path="target/scala-2.11/twirl/main"/>
Refresh your Eclipse project to pick up the change.
I had the same issue, also with Scala IDE 4.0.0 . I followed mkurz instuctions and they worked like a charm. But instead of changing the .classpath file in the project folder manually I used Eclipse interface:
In the top menu of the main window, click on Project and then on Properties.
In the Properties window, click on Java Build Path option (options list is on the left)
In the Source tab, click on Add Folder... button.
In the Source Folder Selection window, choose the target/scala-2.11/twirl/main folder, so it is included in the compilation path. Click Ok button.
Click Ok in the Properties window.
Now the project should compile just fine :) . With that I was able to finish the play setup example in Scala IDE website
I tried #mkurz solution first, but also ran into the same error as #matt. I became frustrated that I could not generate the eclipse project without having to go to the Eclipse project properties to manually fix the build errors. After some investigation, I discovered the solution that removed all errors entirely. Add this your build.sbt:
unmanagedSourceDirectories in Compile <+= twirlCompileTemplates.target
Or if that does not work for you, you could also use:
unmanagedSourceDirectories in Compile <+= target.zipWith(scalaBinaryVersion) { (b,v) => b / s"scala-$v/twirl/main" }
Good bye, build errors!
I got the same error message.
Are you using java8 as jre in eclipse?
After switching back from java8 to java7, everything worked fine again.
If, after following Mkurz' instructions (adding EclipseKeys.CreateSrc... ), your problems are not solved, click on Project -> Properties -> Java Build Path. Look at the source folders tab.
You may find a duplicate file folder named .../src_managed/main (Thanks Matt). If so, close the project. Remove ONE of the two ../src_managed/main entries from the .classpath file (located in the base of the activator/SBT project directory). Reopen and clean the project and you should be good to go.
For me, it turned out that installed JRE in the Scala IDE was openjdk, changed it to Oracle Java 8 and it worked.

Can anyone help me fix this m2e-jdt/jdt bug?

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.

Running tests on Intellij: Class not found

I'm evaluating IntelliJ (13.0.2 133.696) and cannot get jUnit tests to run from within the IDE.
My project is a multi module gradle project and uses scala.
Test class is located under src/test/scala/xxx/xxxxx/xxx/xxxx/xxxxx and everytime i try to run from IDE i get the same error:
Class not found: "xxx.xxxxx.xxx.xxxx.xxxxx.AccountRepositoryTest"
Test class is nothing fancy, simple jUnit test:
#RunWith(classOf[SpringJUnit4ClassRunner])
#ContextConfiguration(classes = Array(classOf[DataConfig], classOf[SettingsConfig]))
class AccountRepositoryTest extends AssertionsForJUnit {
I've found a related question Cannot run Junit tests from IDEA 13.0 IDE for imported gradle projects , but the provided fix (upgrade to 13.0.2) does not work.
I've even tried upgrading to the latest EAP, still the same issue.
I looked through some of these answers, fussed with Project Settings, tried a few things, etc. and nothing worked. (Full disclosure: I'm not trying to juggle Gradle here; I'm just using Maven, but I don't see what this has to do with Gradle.)
I'm using IDEA 14.
What I found to work, because it just simply seemed IntelliJ had lost its way, was this:
$ rm -rf .idea project-name.iml
Then relaunched IntelliJ and did File -> Open -> navigate to the root of my project, etc.--in short, just recreated my project.
IntelliJ got over it. I may have messed something up originally in this project as I had done plenty of refactoring both package- and class names and I had even changed the project name. (It was probably my fault it happened.)
I had this same problem, and in my case the problem was due to the "Project compiler output" path being left blank in Project Settings.
To fix it I created a classes directory in my project root, and set Project compiler output to the absolute path (use the … button to browse).
Go to Project Settings -> Project.
Fill in Project compiler output:
ex. D:\repo\Project\out
Go to Module -> Paths
Make sure that:
output path is like D:\repo\Project\out\production
test output path like D:\repo\Project\out\test
Should work!
Simply 'Build > Rebuild Project' worked for me.
Check Run/Debug configuration for that test
"Use classpath and SDK of module:" should point into your module.
In meantime you module must have a Scala facet and that class must be inside the
"Test source Folders".
You can try to invalidate the cache and restart. That usually will resolve issues when you add new dependencies / classes.
Make sure your test class package and the class for which you are writing test case are not same. If both test case and the class is having the same package, the compiler will look in the src folder and ignores the test folder.
I had the same problem. I changed a path in Module Settings -> Modules -> Paths -> Test output path to my directory for test classes bytecode (exclude output paths on). Now everything works!
IDEA restart solved the issue for me.
Just make shure the folder of your test file marked as a test folder in Intellij IDEA. That worked for me.
If you have multiple directories with source files with the same name, add package to your class source file, if not present!
I had the same problem, Intellij wasn't finding the Test output path. Running the regular application had no problems however.
For me, the fix was changing from inherited project compile paths, to using module compile output paths.
Project Settings -> Modules -> (Your module) -> Paths (tab)
Change the radio select button to "Use module compile output path". For me the autofilled suggestion worked, you may need to manually put in the correct Test Output Path if the autosuggestion doesn't work. Remember to apply the settings change.
As of for gradle project X, deleting both:
X/build
X/out
and running tests again helped me resolve this issue.
Try this in this order:
rebuild project (+strangely, select another app, reselect idea for context-switch, seems to force files reload ?!)
invalidate cache/restart idea
reimport project /create a new project
Just renaming the file to something different and back worked for me :)
modify the content in tag of the module's .iml file just as the following. It works for me.
<content url="file://$MODULE_DIR$">
<sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" />
<sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" />
<excludeFolder url="file://$MODULE_DIR$/target" />
</content>
Had the same problem, fixed it by recreating the project in a directory path that had no spaces, colons, periods or other special characters anywhere in the full path. Apparently IntelliJ can be finicky about the project path.
My issue remained after building, clean and rebuild, closing and opening the project (using intellij), project compiler output was correct; in the end I just deleted the folder out from my project directory. Note that my issue was only on the newly added Junit calling a newly added method. The rest of Junits were working fine.
For me it was that one test was failing and the error was misguiding.
So:
I re-imported module in intellij as standalone project
Run the test
Fix test issues
Run modules again and it started to work.
tl;dr:
Missing file extensions can cause this error.
details:
In my case the test classes were missing the .java extension. E.g. a
file named UserTest instead of UserTest.java
Was hard to find, everything looked normal from within the IDE
(apparently IntelliJ rather uses the file contents to display a
corresponding symbol).
Was not an issue as long as I used mvn from command line (with the surfire plugin enabled in pom.xml) or a dedicated maven launcher configuration, but caused
the initial error message when launching using IntelliJs test or coverage menu / buttons.
Everything working as expected as once I added the missing file endings.
The root cause might be hidden in Java Compiler settings, it was so for me at least. In particular, feel free to adjust those settings using some hints from another thread.

ScalaTest Run Configuration in Eclipse: cannot find Suite Class

Problem: I cannot setup Run Configurations to run scalatest for the Scalatests in my project.
Steps to reproduce:
Right click on Scala Suite and click on Run as -> Run configurations..
On the left, I see a configuration template for ScalaTest. I click on New and fill the Name but it cannot find the suite-class.
Note: It is mentioned here that I should see Run as -> ScalaTest - Suite but I do not see that option. I tried using context menu in the editor, and in the package explorer
Steps taken:
Using: Scala IDE for Eclipse version: 2.1.0.m3-2_09
Using SBT, assemble project, run eclipse command and then import project and dependencies into Eclipse
Project compiles. ScalaTest code compiles(scalatest_2.9.2-1.8.jar is in the 'Referenced Libraries' configuration)
I've been fighting a similar problem for the past few days; Lily / Jimbo's answer didn't quite match my situation, but helped me find the right direction.
In my case, I was using a third-party library that I'd copied in. The package names of the classes and tests matched, but the folder structure did not -- all of my tests were directly in Play's "/test" folder, rather than in folders that matched the package names. This didn't show any errors, but was broken: packages ought to match folders. When I built the right folder structure underneath test, and recompiled, the expected "Run As -> ScalaTest - Suite" options showed up.
Don't know if your problem is the same, but you might check this if you haven't already found the issue...
This could be caused by a misalignment between the scalatest and the scala eclipse IDE version. Try scalatest_2.9.0-2.0.M5b.jar or scalatest_2.10-2.0.M5b.jar. The former jar definitely works with ide 2.0.9.x so maybe the new version needs the 2.10 jar. Pick your version carefully from here
Willem's answer is what worked for me. Getting both plugins from the same update site (from the list on Scalatest's github site), seemed to work for me using Kepler.
for my case, one click on 'Reimport All Maven Projects' icon, like 'Refresh' icon, solved the problem.
Not sure if you fixed the error, but I had similar a error yesterday and was pulling my hair trying to fix it (none of the suggestions I found by googling seemed to help me). So for me, it turns out that it's as easy as package hierarchy in my test suite.
I am using the play framework, so naturally my folders look like this controllers.package1.package2.... and this applies to my test folders also.
Now my test classes however, have the package definition package1.package2..... (no "controllers" as prefix).
If I run the tests on sbt/play command prompt, it's not a problem. But running them through Eclipse would give me the problem you described.
So anyways... thought I'd share this, in case this could help.
it's a bit annoying combined with the view template compile issue in play framework. but my approach is to regenerate the eclipse project file and add view template path into the class path

Groovy Eclipse can't launch junit tests

In Eclipse with groovy plugin, I try to launch a test #Test public void testToLaunch() {...} but I have the error:
The input type of the launch configuration does not exist
What input type is in the context of launch configuration? (can't find such an entry in launch configuration window)
Note: I try sts 2.8.1 and e3.7
This happens normally when the folder in which test case is present is not a source folder, please check this post as well.
Hope that helps!
This can also happen if there is a problem with the groovy class. A few things to check:
1) Ensure that the class name exactly matches the filename (filename = MyTest.groovy)
package com.mypackage;
import groovy.util.GroovyTestCase;
class MyTest extends GroovyTestCase {}
2) Ensure that the package defined in the file matches the package the file is actually in.
In Eclipse you can do
Right click -> properties -> Java build path
Notice test folder is not available in sources. Add it.
Add folder -> Select test -> OK
Now rerun you unit test cases.
This happened to me, and I just restarted Eclipse (GGTS) and everything was fine again.
I had a spelling mistake which lead to that error message. My test class file name was named JUnit5Test.java (with upper U) and the class itself was named Junit5Test (with lower u).
I was using Spring Tool Suite 4 (4.8.0.RELEASE).
This also happened to me. But these tests are written in Groovy. The problem I encountered has to do with how the IDE (Eclipse Kepler, Java EE) first opens a Groovy project after executing "mvn eclipse:eclipse".
The Build Paths do not reference the Groovy source files correctly.
To resolve, I:
Right-click on the project, select "Build Path" > "Configure Build Path..."
Select "Source" tab
For test and src folders (.../src/main/groovy, and .../src/test/groovy)
make sure "**/*.groovy" is set as "Inclusion patterns", not "**/*.java"
Hope this saves time for someone.
Cheers!
I had the same error message when I head the test-class duplicated both in the main Java source folder and the testsrc folder. Removing the incorrectly placed one in the main Java source folder solved the problem for me.
2019 Update: This drove me crazy for days even with latest Eclipse and fresh installs (Mac, Grails 4, Gradle 5.1.1, Java 8). Some above examples led me to the solution.
My problem was more that the code I was testing included a mix of groovy and java src/main code. It gave me NoClassDefFound on the .groovy classes when I ran my Spec as JUnit.
Solution: I had to modify my Run/Debug Configuration to include build/classes/groovy/main. Then it worked. It's a little bit of a pain to remember to that for every new Configuration, but, it keeps me going. I hope it helps you.
Whenever you create a Junit test in eclipse, make sure your Junit test file is inside src/test/java folder.
I had a similar problem. Like others have already pointed out, it was about source folders. I had to change my source folder setup. There was an empty src-folder that disappeared after I right-clicked on it and selected 'remove from build path' from Build path menu. After that I right-clicked both java/src and java/test folders and chose Build path > Use as a source folder. And suddenly my tests were JUnited!
In similar situations I'd advice to remove all source folders from build path and add them again when you're sure you've got the right ones. Your source folders should be those with Java package structure under them. In case of proj/java/test/com/stackoverflow/main it's the 'test' folder.
This is what resolved for me (Eclipse Oxygen). I had already done what Robert suggested in the earlier post. I was still getting the error. When I went to edit the configuration for junit launch, I saw that the Test Class field just had the class name. I had to hit the Search button to the right. The Test Class field now had the complete name for the class
com.mycompany.mypackage.MyClass
With this I am able to run the JUnit. But I have to keep fixing this for every run.
Found another way to cause this message. The cause turned out to be an empty copy of MyTest.java under src/main/java, as well as the real one under src/test/java.
Think the empty file was a hangover from some refactoring and was oddly causing no compile errors either. Deleting it enabled the test to run again.