[
https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated NPANDAY-505:
---------------------------------
Attachment: 0001-NPANDAY-505-support-wildcards-in-registry-elements.patch
Didn't end up using this, so left it out, but might come in handy again in
future. Attachment contains a patch to the WinRegistry to support searching
some very basic wildcards (e.g. iterating the Windows SDK versions available).
> 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
>
> Attachments:
> 0001-NPANDAY-505-support-wildcards-in-registry-elements.patch
>
>
> 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\[email protected]"}</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 was sent by Atlassian JIRA
(v6.2#6252)
