[ 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\.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 was sent by Atlassian JIRA (v6.2#6252)