Reputation: 2038
We use Gradle for the dependency management and for the deployment of the application. Our application is a regular Java application with a public main() method. Eclipse allows the starting of the application directly over a context menu (without Gradle).
However Eclipse adds the test classes to the class path. Since we use Spring configuration annotations for the test classes and for the actual applications we get conflicts. E.g. the database connection is instantiated twice Which leads to startup errors.
Is there a way to tell Eclipse to exclude the test classes to be added to the class path?
I know there is a gradle plugin 'applications', which allows the compilation and starting of the application. However we need to run multiple applications in parallel, which leads to lock issues with the gradle plugin.
Edit: I was unclear: The issue is that the project (libs.core) on which the actual project (applications.core) depends on has test classes which are included. The test classes of the actual project are not included in the Java class path.
For all projects we have the following structure:
Java Classes: src/main/java/
Test Classes: src/test/java
The .classpath file of the 'libs.core' project file contains the following:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="output" path=".eclipse-classes"/>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="src" path="src/main/resources"/>
<classpathentry kind="src" path="src/test/java"/>
<classpathentry kind="src" path="src/test/resources"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER" exported="true"/>
<classpathentry sourcepath="[path to gradle cache]commons-logging-1.1.3-sources.jar" kind="lib" path="[path to gradle cache]commons-logging-1.1.3.jar" exported="true"/>
[other dependencies]
</classpath>
The .classpath file of the 'applications.core' project file contains the following:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="output" path=".eclipse-classes"/>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="src" path="src/main/resources"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER" exported="true"/>
<classpathentry kind="src" path="/libs.core" exported="true"/>
<classpathentry sourcepath="[path to gradle cache]commons-logging-1.1.3-sources.jar" kind="lib" path="[path to gradle cache]commons-logging-1.1.3.jar" exported="true"/>
[other dependencies]
</classpath>
Upvotes: 1
Views: 1050
Reputation: 11
I'd like to add on to the answer given by Rene Groeschke regarding the Eclipse Run Configuration, and to answer the question: "Is there a way to tell Eclipse to exclude the test classes to be added to the class path?"
Navigate to: Run Configuration > Java Application > Classpath: there is a checkbox at the bottom that says "Exclude test code".
This is a simple way to implement his suggestion to exclude src/test from the run configuration. I ran into a similar issue where junit beans where conflicting with running the application, this made a big difference.
Upvotes: 1
Reputation: 28653
The problem is, that eclipse doesn't understand the difference between test code and production code. As Makoto pointed out usually main code lays in src/main/java
and test code in src/test/java
. But even when following these conventions eclipse will pickup code from src/test/java
when running your app. I see two options for you at the moment:
The clean solution would be that eclipse finally starts supporting different types of sources as idea does for years and java user all over the world are asking for for years.
cheers, René
Upvotes: 2
Reputation: 106440
It sounds like a disorganized project structure.
Maven prescribes a standard way to segregate your source code, which is something that Gradle respects. One would typically have their source in src/main/java
, and their test code in src/test/java
, both of which would be followed by the typical package hierarchy.
I would encourage you to move your test files to that structure. Provided the packages are still correct and sound, Gradle will run your tests successfully.
Upvotes: 1