Classpath in run configurations - source root vs. test source root

Hello,

In a Maven 3 project, some dependencies can be in a "provided" scope[1].

Based on the linked document, these dependencies are supposed to be present at compile time, and test time.

If I have a project with a JUnit test class in src/test/java, then the provided dependencies are correctly added to the run configuration's classpath. However, if the JUnit test class is in src/main/java, then IDEA offers to launch the JUnit test in a new run configuration but does not add the provided dependencies to the classpath.

Having a JUnit test in src/main/java sure is unusual, but we have a use case where multi-module projects include a separate module that contains all the system tests in src/main/java. Those are not run at build time but only from the IDE when targetting the deployed application.

Since IDEA 13 actually sees that these classes are JUnit test classes and offers to run them as such, I would expect the IDE to include the dependencies in the "provided" scope. The classpath of the JUnit test is incorrectly built in this case.

Any thoughts on this?

Best regards,

Sébastien

[1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

4 comments
Comment actions Permalink

Hello.

This looks like disputable: http://youtrack.jetbrains.com/issue/IDEA-107048

To be honest, I did not read all comments there, but in the beginning the discussion was about that:
http://youtrack.jetbrains.com/issue/IDEA-107048#comment=27-504586
http://youtrack.jetbrains.com/issue/IDEA-107048#comment=27-504806

Regards,
Alexander.

0
Comment actions Permalink

Hello Alexander,

Ok, I've read all the comments. What I mainly saw was many people asking for a bug fix and one arguing that they're wrong. The number doesn't necessary mean that they're right, and the guy has some good points but I side with the people asking for the situation to be fixed.

However, it doesn't relate 100% to this thread. It's still about building the classpath with or without the provided dependencies, but here there is a different point:

- If the class is in the "source" folder, the provided dependencies are not present
- If the class is in the "test source" folder, the provided dependencies are here

By the definition of the "provided" dependency, those libs should be added during the test phase.

If I can run a class as a unit test, then the classpath must be the one related to the "test" phase, and include the provided dependencies. It should not depend on the fact that the directory is marked as "source" or "test source".

0
Comment actions Permalink

The specific of you case seems to be clear to me. Well, here we have quite common situation: more specific requirement is made when more general requirement (IDEA-107048) is not yet implemented. You can describe your case in the comment there, or create new small issue dedicated exactly for running tests from main root with provided dependency.

BTW, how do you edit pom.xml to make tests from src/main picked on the test phase? For me Maven "test" goal picks only classes from src/test/nnn, not from src/main/nnn root.

Thanks,
Alexander.

0
Comment actions Permalink

The tests are not run during the "test" phase, and it's precisely why we place them in src/main/java.

As I explained (but maybe with too few details, sorry about that), in each of our projects, we include a "SystemTest" module that contains system tests in src/main/java. Those tests are not run during the build, but launched by the developer, from the IDE. They target the deployed application (usually deployed on a local JBoss server), not local classes as unit tests would. Contrary to unit tests, these system tests simulate a real client request to the application. The requests goes through the different layers of the app, just like a client request would.

The system test module is not packaged with the app, and it so it doesn't go to the production environment. It's purely a development artifact.

So as you can see, we don't need to do anything in the pom.xml: the module is built as if it was any other module in the project.

I agree that the problem is closely related to the existing issue, but I'll create an issue just to address the coherence problem, we'll see how it goes.

Thanks for your help!

Sébastien

0

Please sign in to leave a comment.