[jira] [Created] (NPANDAY-505) Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)

[Lars Corneliussen (Created) (JIRA)]

Move vendor detection to Java code (hence remove NPanday.Plugin.Settings)
-------------------------------------------------------------------------

                 Key: NPANDAY-505
                 URL: https://issues.apache.org/jira/browse/NPANDAY-505
             Project: NPanday
          Issue Type: Improvement
          Components: Development Setup, Maven Plugins
    Affects Versions: 1.4-incubating
            Reporter: Lars Corneliussen
            Assignee: Brett Porter
             Fix For: 1.5.0-incubating


Currently NPanday "sometimes" generates a {{npanday-settings.xml}}-file; 
preferably in {{~/.m2}}. Currently this is done by 
NPanday.Plugin.Settings:generate-settings. The problem is, that the file is 
needed to compile the plugin that generates it. That makes it hard to bootstrap 
without a path.

h2. New Approach
We create a master "superset" configuration {{npanday-settings.xml}} (or better 
{{supported-vendors.xml}}?? that contains all frameworks and vendors NPanday 
supports. Then based on various rules, NPanday checks which combinations of 
vendor, vendorVersion and frameworkVersion(s) are available on the current 
platform (registry and path lookup, as currently done in generate-settings).

h2. Example

Currently this code:
{code:title=plugins\netplugins\NPanday.Plugin.Settings\src\main\csharp\DotnetSdkLocator.cs}
..
RegistryKey Microsoft_NETFramework = 
Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\.NETFramework");
RegistryKey Microsoft_SDKs_NETFramework = 
Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\SDKs\.NETFramework");
..
return PathUtil.FirstExisting(
                registryFind(Microsoft_NETFramework, "sdkInstallRootv2.0"),
                registryFind(Microsoft_SDKs_NETFramework, "v2.0", 
"InstallationFolder"),
                ProgramFilesX86(@"Microsoft.NET\SDK\v2.0"),
                ProgramFilesX86(@"Microsoft.NET\SDK\v2.0 64bit"),
                ProgramFilesX86(@"Microsoft SDKs\Windows\v6.0A\bin"),
                ProgramFiles(@"Microsoft SDKs\Windows\v6.0A\bin")
                );
{code}

Generates this:

{code:title=~\.m2\npanday-settings.xml}
...
    <vendor>
      <vendorName>MICROSOFT</vendorName>
      <vendorVersion>3.0</vendorVersion>
      <frameworks>
        <framework>
          <frameworkVersion>3.0</frameworkVersion>
          <installRoot>C:\Windows\Microsoft.NET\Framework64\v3.0</installRoot>
          <sdkInstallRoot>C:\Program Files\Microsoft.NET\SDK\v2.0 
64bit\</sdkInstallRoot>
          <executablePaths>
            
<executablePath>C:\Windows\Microsoft.NET\Framework64\v2.0.50727</executablePath>
            <executablePath>C:\Program Files\Microsoft.NET\SDK\v2.0 
64bit\bin</executablePath>
          </executablePaths>
        </framework>
      </frameworks>
    </vendor>
...
{code}

{code:title=components\dotnet-core\src\main\resources\META-INF\npanday\npanday-settings.xml}
...
  <vendors>
    ...
    <vendor>
      <vendorName>MICROSOFT</vendorName>
      <vendorVersion>3.0</vendorVersion>
      <frameworks>
        <framework>
          <!-- new !! -->
          <frameworkArchitecture>AMD64</frameworkArchitecture>          

          <frameworkVersion>3.0</frameworkVersion>
          
          <!-- registry (Software\Microsoft\.NETFrameworkd@InstallPath) allways 
finds Framework64 on 64bit windows; hence path is better -->
          
<installRoot>${env.WINDIR}\Microsoft.NET\Framework64\v3.0</installRoot>
          
          <!-- first one wins -->
          <sdkInstallRootProbingPaths>
            
<sdkInstallRootProbingPath>${HKLM\Software\Microsoft\.NETFramework@sdkInstallRootv2.0"}</sdkInstallRootProbingPath>
            <sdkInstallRootProbingPath>${HKLM\SOFTWARE\Microsoft\Microsoft 
SDKs\.NETFramework\v2.0@InstallationFolder}</sdkInstallRootProbingPath>
            
<sdkInstallRootProbingPath>${env.ProgramFiles}\Microsoft.NET\SDK\v2.0</sdkInstallRootProbingPath>
            <sdkInstallRootProbingPath>${env.ProgramFiles}\Microsoft 
SDKs\Windows\v6.0A\bin</sdkInstallRootProbingPath>
            <sdkInstallRootProbingPath>${env.ProgramFilesX86}(@"Microsoft 
SDKs\Windows\v6.0A\bin"}</sdkInstallRootProbingPath>
          </sdkInstallRootProbingPaths>

          <executableProbingPaths>
            <!-- 3.0 doesn't come with new tools -->
            
<executableProbingPath>${env.WINDIR}\Microsoft.NET\Framework64\v2.0.50727</executablePath>
            
            <!-- we could by default add installRoot and sdkInstallRoot(+bin) 
-->
            <!-- executableProbingPath>C:\Program Files\Microsoft.NET\SDK\v2.0 
64bit\bin</executablePath -->
          </executableProbingPaths>
        </framework>
      </frameworks>
    </vendor>
    ...
  </vendors>
...
{code}

Both registry access with ${HKLM*}, ${HKCU*}, ${HKEY_LOCAL_MACHINE*}, 
${HKEY_CURRENT_USER*} and ${env.*} should work. I'd suggest to let 
${env.ProgramFilesX86} fall back to ${env.ProgramFiles} for non-64-bit - (add 
an item to the properties in {{ContextAwareModelInterpolator}})

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira