Expansion of maven variables

[Simon Kitching <sk...@apache.org>]

Hi,

I'm confused by the availability of maven variables, in particular
${project.testClasspathElements}.

In a surefire config section, I've got this:

    <configuration>
      <includes>
        <include>**/DumpProps.java</include>
      </includes>
      <systemProperties>
        <property>
          <name>test.finalName</name>
          <value>${project.build.finalName}</value>
        </property>
        <property>
          <name>test.artifactId</name>
          <value>${project.artifactId}</value>
        </property>
        <property>
          <name>test.version</name>
          <value>${project.version}</value>
        </property>
        <property>
           <name>testclasspath</name>
           <value>${project.classpathElements}</value>
        </property>
      </systemProperties>
    </configuration>

When run, I get this output:
 test.testclasspath:${project.testClasspathElements}
 test.classpath:${project.classpathElements}
 test.finalName:commons-logging-1.1.1
 test.builddir:${project.build.directory}
 test.artifactId:commons-logging
 test.version:1.1.1

There are clearly a number of variables that don't get expanded. However
all of these are listed as variables in the maven-surefire-plugin docs:
  http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
and of course this documentation is derived straight from the
annotations in the sourcecode:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java


Can anyone explain what's happening here?

Just FYI, what I'm trying to do is pass ${project.testClasspathElements}
to the unit tests so that each test can control its own classpath,
ordering the jars however it needs using a custom classloader. As an
alternate approach, I hoped the assembly:unpack target could be used to
copy dependencies into a subdir of target, so I could hard-wire paths to
them in the sysprops but that isn't working as I do not want the jars
unpacked. Any suggestions for other approaches would be welcome.

Thanks,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Expansion of maven variables

[Gilles Scokart <gs...@hotmail.com>]

${project.classpathElements} can be used when your parameter is a List . 
Here you want to place it in a String.

Moreover, I think that the expension done into the pom, and the things done
in the plugin is different. So, there is maybe some differences. 
-- 
View this message in context: http://www.nabble.com/Expansion-of-maven-variables-tf1996470.html#a5480707
Sent from the Maven - Users forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Expansion of maven variables

[Simon Kitching <sk...@apache.org>]

Hi Gilles,

Thanks for your comments.

On Mon, 2006-07-24 at 23:48 -0700, Gilles Scokart wrote:
> ${project.classpathElements} can be used when your parameter is a List . 
> Here you want to place it in a String.

True, and maybe that's the problem. The things that are working are all
of type String.

The data is magically managed via the declaration:
 /**
  * @parameter
  */
 private Properties systemProperties;

I believe that it is the plexus container that implements the necessary
"dependency injection" stuff to take the xml in the pom.xml file and map
it into a Properties object and assign it to systemProperties. Obviously
that code is buried deep down inside plexus where normal mortals can't
see.

A Properties object does implement Map and therefore potentially
supports objects, but the surefire code clearly doesn't support this
(and reasonably too):
   // Add all system properties configured by the user
   Iterator iter = systemProperties.keySet().iterator();
   while ( iter.hasNext() )
   {
     String key = (String) iter.next();
     String value = systemProperties.getProperty( key );
     System.setProperty( key, value );
   }

In my case, it would be ok for the classpath to be mapped from a List to
a string that the unit tests can parse; I therefore tried
  ${project.classpathElements.toString()}
but unfortunately that didn't work either. Oddly, neither did
  ${project.artifactId.substring(8)} 
when used in the properties section, though that expression certainly
does work in other places in the pom. Scary; I thought that this
variable handling/injection was being managed by Plexus and therefore
would work consistently everywhere but that doesn't seem to be the case.


If it's not going to be possible to map the classpath into a string so
it can be passed as a system property, can anyone else suggest a way for
the unit tests to obtain the surefire test-classpath? The unit tests are
explicitly run in a custom classloader to isolate them, so even if there
is some singleton method that the unit tests could call to obtain a
reference to the project object or the surefire plugin object, I expect
they wouldn't be able to see it.

I see that the existing code explicitly sets "basedir" and
"localRepository" system properties so unit tests can retrieve these.
Maybe this could be generalised..


> 
> Moreover, I think that the expension done into the pom, and the things done
> in the plugin is different. So, there is maybe some differences. 

Isn't it all done by Plexus?

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org