You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-commits@incubator.apache.org by "Lars Corneliussen (Created) (JIRA)" <ji...@apache.org> on 2011/12/20 11:47:30 UTC
[jira] [Created] (NPANDAY-505) Move vendor detection to Java code
(hence remove NPanday.Plugin.Settings)
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
[jira] [Commented] (NPANDAY-505) Move vendor detection to Java code
(hence remove NPanday.Plugin.Settings)
Posted by "Brett Porter (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174019#comment-13174019 ]
Brett Porter commented on NPANDAY-505:
--------------------------------------
I agree, conventions are good. So if we can hit the default configuration of Windows / Mono in a distributed file, then let users override it with a settings file, that's great.
For locating frameworks in different places, the current generation should still be ok, and can be made a standalone task rather than incorporated in the lifecycle.
I would like to check how we can integrate this with toolchains in Maven - but that needs to be a separate task as it'll mandate Maven 3.
> 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
[jira] [Commented] (NPANDAY-505) Move vendor detection to Java code
(hence remove NPanday.Plugin.Settings)
Posted by "Brett Porter (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174018#comment-13174018 ]
Brett Porter commented on NPANDAY-505:
--------------------------------------
A short note on the intro: at the moment, it is impossible to bootstrap without a path, as the build fails due to the missing file. So this is a blocker for 1.5.0
> 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