Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.4-incubating
-
Fix Version/s: 1.5.0-incubating
-
Component/s: Maven Plugins
-
Labels:
-
Environment:Hide
$ mvn -v
Apache Maven 2.2.1 (rdebian-4)
Java version: 1.6.0_24
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"Show$ mvn -v Apache Maven 2.2.1 (rdebian-4) Java version: 1.6.0_24 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.35-28-generic" arch: "amd64" Family: "unix"
Description
When npanday-test-plugin is constructing the command line to execute unit tests with the NUnit console, it uses the executable name "nunit-console2".
On Ubuntu 10.10, the nunit-console 2.4.7 package ships with /usr/bin/nunit-console but no executable named nunit-console2, resulting in the following build error.
[INFO] [INFO] /bin/sh: nunit-console2: not found [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------
Activity
As a workaround, the maven-test-plugin can be configured as follows:
<plugin>
<groupId>npanday.plugin</groupId>
<artifactId>maven-test-plugin</artifactId>
<version>${npanday.version}</version>
<configuration>
<nunitCommand>${nunit.command}</nunitCommand>
</configuration>
</plugin>
...and then the user's settings.xml can have a profile as follows:
<settings>
<profiles>
<profile>
<id>nunit.console2</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<nunit.command>nunit-console</nunit.command>
</properties>
</profile>
</profiles>
</settings>
...but then that would be configuration over convention. 
Hm,
looks like we added nunit-console2 just for Mono in order to support both 1.1 and 2.0.
At least that is what I see from this code:
private String getExecutableFor( VendorInfo vendorInfo )
{
String exe;
if ( nunitCommand == null )
{
// nunit-console-x86 is included since 2.4.2 (August 2007, http://www.nunit.org/index.php?p=releaseNotes&r=2.4.3)
exe = "nunit-console" + (forceX86 ? "-x86" : "");
if ( vendorInfo != null )
{
Vendor vendor = vendorInfo.getVendor();
String frameworkVersion = vendorInfo.getFrameworkVersion();
if ( "MONO".equals( vendor.getVendorName() ) )
{
if ( frameworkVersion == null || !frameworkVersion.startsWith( "1.1" ) )
{
exe = "nunit-console2";
}
}
}
}
else
{
exe = nunitCommand;
}
return !( nunitHome == null || nunitHome.equals( "" ) ) ? nunitHome + File.separator + "bin" + File.separator
+ exe : exe;
}
Is that plainly wrong?
It seems that some earlier distributions had distinguished the 2.0 Mono runtime from the 1.1 Mono runtime by having both nunit-console and nunit-console2 executables on the path, presumably for backwards compatibility.
However, the Mono distribution for Ubuntu 10.10+ currently uses the 2.0 Mono runtime for nunit-console executable, and nunit-console2 does not exist. Therefore, the current convention breaks the build when nunit-console2 cannot be found.
The contents of nunit-console are as follows:
$ which nunit-console
/usr/bin/nunit-console
$ cat /usr/bin/nunit-console
#!/bin/sh
exec /usr/bin/cli /usr/lib/nunit/nunit-console.exe "$@"
$ ls -l /usr/bin/cli
lrwxrwxrwx 1 root root 21 2010-02-22 00:03 /usr/bin/cli -> /etc/alternatives/cli
$ ls -l /etc/alternatives/cli
lrwxrwxrwx 1 root root 13 2010-02-22 00:03 /etc/alternatives/cli -> /usr/bin/mono
It looks as though an attempt was made to retain some degree of backwards compatibility for direct references to nunit-console2.exe, as shown by the contents of /usr/lib/nunit.
$ ls -l /usr/lib/nunit lrwxrwxrwx 1 root root 17 2011-04-19 16:34 nunit-console2.exe -> nunit-console.exe -rwxr-xr-x 1 root root 4096 2010-01-29 00:59 nunit-console.exe -rw-r--r-- 1 root root 3736 2010-01-29 00:59 nunit-console.exe.config -rw-r--r-- 1 root root 19456 2010-01-29 00:59 nunit-console-runner.dll
Ideally, the nunit-console executable would be located using the same mechanism as for other executables like csc and gmcs.
This would also address the problem with having an absolute path for nunitCommand on non-Windows platforms, where leading / in the absolute path is confused with the windows-based / used for command flags.
At present, the best known workable solution for non-Windows platforms is to explicitly put the directory containing nunit-console on the environment path, which is not desirable given all the hard work already put in to making sure global paths were not required for any other executables.
Fixed in r1145776, r1145777 and routed through NetExecutableFactory to easily support framework version alignment between compile and test plugins.
Note that adding /usr/lib/nunit as an executablePath in npanday-settings.xml does not appear to help.