+1 for adding <dependencies /> to both the <build /> and <unitTest />
directories.  The current dependencies element could be inherited into the
build and unitTest dependencies.  This would allow for the "specification"
jar to be used for the build, and the "implementation" jar used for
packaging by including it in the current dependency list.

Ryan

-----Original Message-----
From: Alastair Rodgers [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 09, 2004 4:28 AM
To: Maven Users List
Subject: RE: Dependency issues for junit tests

One solution (which I adapted from a post on the turbine-maven-user list) is
to add the extra dependencies to the classpath prior to test compilation and
remove them after your tests are done. What we do is let each project
optionally define a separate POM file, 'project-tests.xml', which lists the
extra dependencies required by the unit tests, e.g.

<project>
  <!-- ====================== -->
  <!-- Unit test dependencies -->
  <!-- ====================== -->
  <dependencies>
    <dependency>
      <groupId>easymock</groupId>
      <artifactId>easymock</artifactId>
      <version>1.0.1b</version>
    </dependency>
  </dependencies>
</project>

We then have a base project which all projects derive from and whose
maven.xml defines a preGoal and postGoals to handle the extra dependencies.
The preGoal saves the current classpath then loads the extra dependencies
from project-tests.xml and adds them to the classpath before test
compilation. The postGoals restore the classpath to the saved value after
the test(s) complete (i.e. after test:test, test:single and test:match). 

Here's what you need to add to the base maven.xml: 

  <!-- ================================================================ -->
  <!-- preGoals / postGoals for "test" plugin:                          -->
  <!--  - Allow test dependencies to be specified separately            -->
  <!--    from source dependencies in a 'project-tests.xml' file.       -->
  <!-- ================================================================ -->
  <preGoal name="test:compile">
    <attainGoal name="addTestDependencies"/>
  </preGoal>
  <postGoal name="test:test">
    <attainGoal name="removeTestDependencies"/>
  </postGoal>
  <postGoal name="test:single">
    <attainGoal name="removeTestDependencies"/>
  </postGoal>
  <postGoal name="test:match">
    <attainGoal name="removeTestDependencies"/>
  </postGoal>

  <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. -->
        <maven: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. -->
      <maven: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>


> -----Original Message-----
> From: Cary Coulter [mailto:[EMAIL PROTECTED] 
> Sent: 09 January 2004 00:30
> To: Maven Users List
> Subject: Re: Dependency issues for junit tests
> 
> 
> Wouldn't it just be better to add the 
> <dependencies>...</dependencies> to the <unitTest> block 
> rather than adding some type of property <type>test</type>" 
> to the regular <dependencies>...</dependencies> area??
> 
> I'd would be glad to try to test something, but I'm still 
> pretty green with Maven.  If I can just update the "test" 
> plugin in the standard 1.0-rc1 world, I can probably manage it.
> 
> Like this (I just found the <resource> needed to include my 
> *.xml in the TEST only path.
> 
>         <unitTest>
>             <includes>
>                 <include>**/**Test.java</include>
>             </includes>
>             <excludes>
>                 <exclude></exclude>
>             </excludes>
>             <resources>
>                 <resource>
>                     <directory>source/test</directory>
>                     <include>**/*.xml</include>
>                 </resource>
>             </resources>
>            <dependencies>
>               <dependency>
>                     <groupId>xxx-yyy</groupId>
>                     <artifactId>test-dep1-code</artifactId>
>                     <version>3.2.0</version>
>                </dependency>
>               <dependency>
>                     <groupId>xxx-yyy</groupId>
>                     <artifactId>test-dep2-code</artifactId>
>                     <version>1.2.3</version>
>                </dependency>
>             </dependencies>
>         </unitTest>
> 
> 
> test-dep1-code.2.3.0.jar and test-dep2-code.1.2.3.jar would 
> only be added to the classpath during junit runs.
> 
> Thanks for your interest -- and any help you can give.
> Cary
> 
> 
> ----- Original Message ----- 
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: "Maven Users List" <[EMAIL PROTECTED]>
> Sent: Thursday, January 08, 2004 2:41 PM
> Subject: Re: Dependency issues for junit tests
> 
> 
> > On Thu, 2004-01-08 at 14:50, Cary Coulter wrote:
> > > How can I specify additional dependent jars for junit tests?
> > >
> > > The main application code (non-junit classes) does not 
> need (nor do 
> > > we
> want
> > > the developers to compile against) several lower level 
> application 
> > > jars (stuff we have built wrappers for to isolate them from our 
> > > code).
> > >
> > > However, in order to run the junit tests, the project 
> needs access 
> > > to
> the
> > > wrapper jars dependencies.  Different projects might need a 
> > > different
> list
> > > of these dependent (non-compile against) jars.
> > >
> > > I can't find a means in the project.xml or project.properties to 
> > > specify
> the
> > > jars to only be used for junit testing.
> > >
> > > Any ideas?
> >
> > If you do the following:
> >
> > <dependency>
> >   <groupId>foo</groupId>
> >   <artifactId>bar</artifactId>
> >   <type>test</type>
> >   <version>1.0</version>
> > </dependency>
> >
> > You can make the distinction. Currently a type that corresponds to 
> > "jar" and "ejb" will be added to the classpath. So by specifying a 
> > type other than those they will be excluded from the classpath.
> >
> > So if you give me a few minutes,  I will alter the test 
> plugin to deal 
> > with test and non-test dependencies. Might as well start now with 
> > allowing this distinction.
> >
> > Cary, if I make this change are you going to test it for me?
> >
> > >
> > >
> > > Thanks in advance,
> > > Cary
> > >
> > > Learning Maven and liking it.
> > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > --
> > jvz.
> >
> > Jason van Zyl
> > [EMAIL PROTECTED]
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational and 
> > technical order to justify his work and to be justified in it.
> >
> >   -- Jacques Ellul, The Technological Society
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to