Hi,
AFAIK, the issue of separate paths for building and testing has not been
addressed in Maven. We have a situation that sounds similar to yours. We
have several test frameworks and we use 0..n of these frameworks in any
given project. However, we do not want these test frameworks to be put in
the compile class path for the regular project source code- we only want the
test frameworks in the compile and run path for the unit tests. Each
test-framework is its own project and is deployed to our central repository.
What we have done is to standardize on an optional project-tests.xml
descriptor that specifies the unit test dependencies for a project. We then
have pre and post test goals that read the dependencies from this optional
pom and add them to the test classpath by calling these 2 goals:
<goal name="addTestDependencies" >
<available
property="testPomPresent"
file="${basedir}/project-tests.xml" />
<j:if test="${testPomPresent}">
<j:set var="testPathX"
value="${pom.getAntProject().getReference('test.path')}X"/>
<j:if test="${testPathX == 'X'}" >
<!-- Read the POM that describes test-specific dependencies and then
verify those dependencies from the repo. -->
<m:pom projectDescriptor="${basedir}/project-tests.xml"
var="testPom"/>
<j:set var="dummyVar" value="${testPom.verifyDependencies()}" />
<path id="test.path" path="${testPom.getDependencyClasspath()}" />
</j:if>
<!-- Save Maven's current class path as a string. Because it is a true
Ant path object, we cannot simply declare a new variable that
references the same object we are about to change. Also, we
cannot
simply use the project's dependencyClasspath attribute because
other
goals, such as clover, also make modifications to Maven's
dependency
class path that we must preserve. -->
<j:set
var="savedPath"
value="${pom.getAntProject().getReference('maven.dependency.classpath').toSt
ring()}" />
<!-- Add test-specific dependencies to the project's Ant-style
classpath
structure. Note that this only modifies the Ant path object and
does
not change the project's dependencyClasspath attribute. -->
<m:addPath id="maven.dependency.classpath" refid="test.path" />
</j:if>
</goal>
<goal name="removeTestDependencies" >
<j:if test="${testPomPresent == 'true'}" >
<!-- Restore Maven's classpath by redefining it. -->
<path id="maven.dependency.classpath">
<pathelement path="${savedPath}" />
</path>
</j:if>
</goal>
I hope this gives you some ideas. Right now, mucking with Maven's dependency
classpath is quite messy. It would be nice if there was a set of
easy-to-use tags so that a plugin could do and undo changes to the
classpath, like a stack. However, this solution works fine for us now.
Regards,
--------------------------------------
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--------------------------------------
> -----Original Message-----
> From: Scott Stirling [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 04, 2003 8:07 PM
> To: 'Maven Users List'
> Subject: Refining dependencies for test and non-test
>
>
> Hi,
>
> Wondering how and whether it's possible to refine a project's
> dependency set
> so that unit/integration test dependencies are separate from non-test
> dependencies.
>
> For example, if I have jars that a JUnit extension library needs
> at runtime,
> but which I don't want to have in the classpath at build time for
> my classes
> (or perhaps my classes require a different version of a jar), how do I
> separate them at compile time and/or runtime?
>
> Thank you,
>
> Scott Stirling
> Framingham, MA
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
