NPanday
  1. NPanday
  2. NPANDAY-409

Executable path ignored during command execution while building NPanday on Linux

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4-incubating
    • Fix Version/s: 1.5.0-incubating
    • Component/s: Maven Plugins
    • Labels:
    • Environment:

      Description

      Checked out NPanday trunk r1095141 on Linux and applied the following patches.
      o NPANDAY-400
      o NPANDAY-402
      o NPANDAY-407 (new)

      The ~/.m2/npanday-settings.xml file looks like this:

      <npandaySettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <operatingSystem>linux 2.6.35-28-generic</operatingSystem>
        <defaultSetup>
          <vendorName>MONO</vendorName>
          <vendorVersion>2.0.50727</vendorVersion>
          <frameworkVersion>2.0.50727</frameworkVersion>
        </defaultSetup>
        <vendors>
          <vendor>
            <vendorName>MONO</vendorName>
            <vendorVersion>2.0.50727</vendorVersion>
            <frameworks>
              <framework>
                <frameworkVersion>2.0.50727</frameworkVersion>
                <installRoot>/usr/lib/mono/2.0</installRoot>
              </framework>
            </frameworks>
          </vendor>
        </vendors>
      </npandaySettings>
      

      When attempting to build on Linux, the error trace below is displayed trying to execute "xsd" and the build fails.

      [INFO] NPANDAY-070-003: Found executable path for xsd: /usr/lib/mono/2.0
      [INFO] Cannot open assembly '/usr/lib/mono/1.0/xsd.exe': No such file or directory.
      [DEBUG] NPANDAY-040-000: Executed command: Commandline = /bin/sh -c cd /usr/lib/mono/2.0 && xsd /home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/Pom.xsd /o:/home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/target/build-sources /classes /language:CS /namespace:NPanday.Model.Pom, Result = 2
      [INFO] NPANDAY-070-003: Found executable path for xsd: /usr/lib/mono/2.0
      [INFO] NPANDAY-070-003: Found executable path for xsd: /usr/lib/mono/2.0
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] NPANDAY-1400-000: Unable to execute xsd: Vendor null, frameworkVersion = 2.0.50727, Profile = XSD:SCHEMA

      Embedded error: NPANDAY-070-000: Execution Path = /usr/lib/mono/2.0, Command = [/home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/Pom.xsd, /o:/home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/target/build-sources, /classes, /language:CS, /namespace:NPanday.Model.Pom]
      NPANDAY-040-001: Could not execute: Command = /bin/sh -c cd /usr/lib/mono/2.0 && xsd /home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/Pom.xsd /o:/home/jfallows/Workspaces/npanday-trunk/dotnet/assemblies/NPanday.Model.Pom/target/build-sources /classes /language:CS /namespace:NPanday.Model.Pom, Result = 2

      The executable that should be used is /usr/lib/mono/2.0/xsd.exe, and it is correctly located in the executable paths.

      Notice that the shell commands "cd /usr/lib/mono/2.0 && xsd" would not execute /usr/lib/mono/2.0/xsd.exe on Linux.

      Conversely, on Windows, the current directory is searched first on the path by default, and the .exe extension can be omitted, which is why this has not shown up as an issue thus far on Windows. On Linux, the default path contains executables such as /usr/bin/gmcs which force a specific version of the Mono runtime to be used, such as 2.0 shown below.

      #!/bin/sh
      exec /usr/bin/mono $MONO_OPTIONS /usr/lib/mono/2.0/gmcs.exe "$@"

      In this case, my /usr/bin/xsd was pointing explicitly at Mono 1.0 unexpectedly, leading to the discovery of this issue.

      If the intent is to support targeting multiple different Mono runtimes for different projects by using executable paths in npanday-settings.xml, then it is necessary to use the fully qualified path complete with .exe extension on Linux.

        Activity

        Hide
        Lars Corneliussen added a comment -

        We indeed want to support different Mono runtimes for different projects. I did some work on this for Windows:

        PathUtil.java
            public static boolean containsExecutable(String executablePath, String executable) {
                File path = new File(executablePath);
                if (!path.exists())
                    return false;
        
                File file = new File(path, executable);
                if (file.exists())
                    return true;
        
                // TODO: handle linux/mac ?
                String[] extensions = new String[] {"exe", "com", "bat", "cmd"};
        
                for (String extension : extensions)
                {
                    file = new File(path, executable + "." + extension);
                    if (file.exists())
                        return true;
                }
        
                return false;
            }
        

        Instead of only checking if there is a corresponding file with any of these extensions, we should also then use this file found.

        Usages of that method should lead you to the corresponding Excecutable-implementations. Do you want to fix this? Would be great!

        Show
        Lars Corneliussen added a comment - We indeed want to support different Mono runtimes for different projects. I did some work on this for Windows: PathUtil.java public static boolean containsExecutable( String executablePath, String executable) { File path = new File(executablePath); if (!path.exists()) return false ; File file = new File(path, executable); if (file.exists()) return true ; // TODO: handle linux/mac ? String [] extensions = new String [] { "exe" , "com" , "bat" , "cmd" }; for ( String extension : extensions) { file = new File(path, executable + "." + extension); if (file.exists()) return true ; } return false ; } Instead of only checking if there is a corresponding file with any of these extensions, we should also then use this file found. Usages of that method should lead you to the corresponding Excecutable-implementations. Do you want to fix this? Would be great!
        Hide
        John R. Fallows added a comment -

        Although Mono can be registered to handle execution of .exe files on Linux, so that the current path is searched for gmcs.exe when gmcs is executed, the Linux PATH takes precedence, so /usr/bin/gmcs is found even when gmcs.exe exists in the current directory.

        This behavioral difference between Windows and Linux was causing the reported error.

        As a workaround on non-Windows platforms, we can use ./gmcs.exe to get gmcs.exe to run in the current directory instead of relying on the behavior of finding gmcs.exe when gmcs is executed.

        Show
        John R. Fallows added a comment - Although Mono can be registered to handle execution of .exe files on Linux, so that the current path is searched for gmcs.exe when gmcs is executed, the Linux PATH takes precedence, so /usr/bin/gmcs is found even when gmcs.exe exists in the current directory. This behavioral difference between Windows and Linux was causing the reported error. As a workaround on non-Windows platforms, we can use ./gmcs.exe to get gmcs.exe to run in the current directory instead of relying on the behavior of finding gmcs.exe when gmcs is executed.
        Hide
        John R. Fallows added a comment -

        Fixed in r1144592.

        Show
        John R. Fallows added a comment - Fixed in r1144592.

          People

          • Assignee:
            Unassigned
            Reporter:
            John R. Fallows
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development