-
Notifications
You must be signed in to change notification settings - Fork 932
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transitive dependencies with classifier "test" are not include in the classpath #2964
Comments
Same issue here, it would be great if this issue will been fixed in next release! |
Been hobbled by this before, and it continues to require awkward project structures where published test artifacts are desired. |
I think part of the issue is that
<configurations>
<conf name="default" visibility="public" description="runtime dependencies and master artifact can be used with this conf" extends="runtime,master"/>
<conf name="master" visibility="public" description="contains only the artifact published by this module itself, with no transitive dependencies"/>
<conf name="compile" visibility="public" description="this is the default scope, used if none is specified. Compile dependencies are available in all classpaths."/>
<conf name="provided" visibility="public" description="this is much like compile, but indicates you expect the JDK or a container to provide it. It is only available on the compilation classpath, and is not transitive."/>
<conf name="runtime" visibility="public" description="this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath." extends="compile"/>
<conf name="test" visibility="private" description="this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases." extends="runtime"/>
<conf name="system" visibility="public" description="this scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository."/>
<conf name="sources" visibility="public" description="this configuration contains the source artifact of this module, if any."/>
<conf name="javadoc" visibility="public" description="this configuration contains the javadoc artifact of this module, if any."/>
<conf name="optional" visibility="public" description="contains all optional dependencies"/>
</configurations> Using classifier to encode this I don't think is good idea either. Basically, if people want to reuse tests, and still want to use Maven repositories, the module should be in |
Uh, so the recommended path to reusing tests (@eed3si9n) is to ship tests in compile of downstream modules because they need some main code? Perhaps I'm just too lazy, but I've always had code and relevant test supports shipped from the same module (but am now trying to migrate sbt to maven publishing...) |
For clarification, I don't mean that people should include tests directly in some library, but split out the reusable parts and call it "foo-testkit". |
steps
These steps make use of the hadoop-mini-cluster project.
problem
It start with the compilation that is successful but issue a warn about a not found resource
Running the test is failing because of a NoClassDefFoundError
(...some update on testing jar...)
Furthermore adding the following dependency:
... just move the problem to anther missing dependency located in a "test-jar"
expectation
In the sbt documentation this can be read:
So I expected (wrongly maybe) that
coupled with the updateClassifiers task would add all the test jar to my dependency. But this is not the case.
notes
Maybe this case should be more documented...
The text was updated successfully, but these errors were encountered: