Multiple Dependency Scopes in POM

Question

I have a dependency in my POM that needs to be set to "provided" so it is not included at compilation, but it can still be referenced within my project. I would like the same dependency to have a scope of "test" when I go to run tests so I do not have to manually add the jar to my classpath. Is there a way to do this or achieve similar results?

Reasoning behind this is that I have some common jars that are provided in my JBOSS lib directory, so I want to use these and keep the "provided" scope of them for the war that is built. However, when I run JUnits from the command line, I want to use the jar from the repository without manually adding it to my classpath.

Thanks in Advance

Solution 1

From maven documentation:

provided This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

I checked this works for me in maven 3.0.3. Had the same issue that i needed to have a servlet dependency while compilation and test but not compiled in because it ships with the application server distribution.

Solution 2

You could use a profile that either declares those dependencies as test or as provided - depending on what is more convenient for you:

<profiles>
    <profile>
        <id>whatever</id>
        <activation>
            <property>
                <name>env</name>
                <value>whatever</value> 
            </property>
        </activation>
        <dependencies>
            <dependency>
              <groupId>yours</groupId>
              <artifactId>yours</artifactId>
                <scope>provided</scope>
            </dependency>
        </dependencies>
    </profile>
    <profile>
        <id>test</id>
        <activation>
            <property>
                <name>env</name>
                <value>test</value> 
            </property>
        </activation>
        <dependencies>
            <dependency>
              <groupId>yours</groupId>
              <artifactId>yours</artifactId>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </profile>
</profiles>

Those profiles get activated by setting the property env but there are other ways, f.e. default activation - have a look here for that.

Solution 3

Try declaring the dependency twice, once with each scope. Works in Maven 2.2.1.

Confusing things happen with dependency resolution, when the same artifact is in the dependency tree twice with different scopes, but I don't think it should be a problem in your case.

Solution 4

Have the same issue, reason why i need two scopes for the same dependency is on phase integrating test i use jetty-plugin for run rest service, and make some JUnit testing while jetty is running, but i compile my package for jboss as, where i already have "resteasy-cdi", than absent for jetty servlet container...I have no found solution yet.

View more solutions

Comments

[Andrew Spencer]

I think OP wants to have provided and test scope in the same build.

[Jan]

@Andrew Spencer: I think the just has different use cases, save he's referring to a test in the same build. Which would be a different thing, of course...

[Adrian Petrescu]

This is the correct answer, at least for my use case. @Steve, you should mark it as accepted :)

[Martin Höller]

This is NOT the Maven way! Dependencies should be stable, regardles which profile is active!

[Jan]

@MartinHöller: I see your point but why is the dependencies section includes in the profile then? There might be use cases when you need other dependencies - which might not influence your deployed build result.

[SebastianH]

In Maven 3.0.5 this solution leads to [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. For this reason, future Maven versions might no longer support building such malformed projects.

[Gangnus]

Maybe it is a good idea, maybe not, but as it is "explained" here, it is absolutely unusable. The same about referenced docs. Apache does good SW, but its docs rarely explain anything.