svn commit: r1221150 - /incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml
Author: lcorneliussen
Date: Tue Dec 20 09:00:42 2011
New Revision: 1221150
URL: http://svn.apache.org/viewvc?rev=1221150view=rev
Log:
Removed unecessary dependency
Modified:
incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml
Modified: incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml?rev=1221150r1=1221149r2=1221150view=diff
==
--- incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml (original)
+++ incubator/npanday/trunk/plugins/maven-ilmerge-plugin/pom.xml Tue Dec 20
09:00:42 2011
@@ -29,11 +29,4 @@ under the License.
packagingmaven-plugin/packaging
nameNPanday :: ILMerge Maven Plugin/name
descriptionMaven Plugin for .NET: Merges assemblies/description
- dependencies
-dependency
- groupIdorg.codehaus.plexus/groupId
- artifactIdplexus-utils/artifactId
- version${plexus.utils.version}/version
-/dependency
- /dependencies
/project
svn commit: r1221151 - /incubator/npanday/trunk/plugins/pom.xml
Author: lcorneliussen Date: Tue Dec 20 09:01:27 2011 New Revision: 1221151 URL: http://svn.apache.org/viewvc?rev=1221151view=rev Log: [NPANDAY-488] Packaging for Web Applications (also Azure Web Roles) o Added MSDeploy plugin as module to parent Modified: incubator/npanday/trunk/plugins/pom.xml Modified: incubator/npanday/trunk/plugins/pom.xml URL: http://svn.apache.org/viewvc/incubator/npanday/trunk/plugins/pom.xml?rev=1221151r1=1221150r2=1221151view=diff == --- incubator/npanday/trunk/plugins/pom.xml (original) +++ incubator/npanday/trunk/plugins/pom.xml Tue Dec 20 09:01:27 2011 @@ -56,6 +56,7 @@ under the License. modulemaven-wsdl-plugin/module modulewix-maven-plugin/module modulepartcover-maven-plugin/module +modulemsdeploy-maven-plugin/module /modules dependencies dependency
svn commit: r1221158 - /incubator/npanday/branches/npanday-1.4.x/pom.xml
Author: brett Date: Tue Dec 20 09:18:01 2011 New Revision: 1221158 URL: http://svn.apache.org/viewvc?rev=1221158view=rev Log: update Maven version Modified: incubator/npanday/branches/npanday-1.4.x/pom.xml Modified: incubator/npanday/branches/npanday-1.4.x/pom.xml URL: http://svn.apache.org/viewvc/incubator/npanday/branches/npanday-1.4.x/pom.xml?rev=1221158r1=1221157r2=1221158view=diff == --- incubator/npanday/branches/npanday-1.4.x/pom.xml (original) +++ incubator/npanday/branches/npanday-1.4.x/pom.xml Tue Dec 20 09:18:01 2011 @@ -35,7 +35,7 @@ under the License. !-- this is what get edited most, so lets put it on the top -- properties -mavenVersion2.0.9/mavenVersion +mavenVersion2.2.1/mavenVersion plexus.utils.version1.5.1/plexus.utils.version !-- if you want to build NPanday with a specific version, replace this -- bootstrap.npanday.version1.4.0-incubating/bootstrap.npanday.version
svn commit: r1221159 - /incubator/npanday/trunk/dotnet/pom.xml
Author: brett
Date: Tue Dec 20 09:19:39 2011
New Revision: 1221159
URL: http://svn.apache.org/viewvc?rev=1221159view=rev
Log:
put back skip
Modified:
incubator/npanday/trunk/dotnet/pom.xml
Modified: incubator/npanday/trunk/dotnet/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/npanday/trunk/dotnet/pom.xml?rev=1221159r1=1221158r2=1221159view=diff
==
--- incubator/npanday/trunk/dotnet/pom.xml (original)
+++ incubator/npanday/trunk/dotnet/pom.xml Tue Dec 20 09:19:39 2011
@@ -105,6 +105,11 @@ under the License.
groupIdorg.apache.npanday.plugins/groupId
artifactIdNPanday.Plugin.Settings.JavaBinding/artifactId
version${bootstrap.npanday.version}/version
+ configuration
+!-- Required until this can be done in Java, as otherwise there is
+ a bootstrapping problem trying to run the goal --
+skiptrue/skip
+ /configuration
/plugin
/plugins
/pluginManagement
svn commit: r1221161 - in /incubator/npanday/branches/npanday-1.4.x: ./ dotnet/pom.xml
Author: brett
Date: Tue Dec 20 09:21:21 2011
New Revision: 1221161
URL: http://svn.apache.org/viewvc?rev=1221161view=rev
Log:
add back skip for documented bootstrap problem
Modified:
incubator/npanday/branches/npanday-1.4.x/ (props changed)
incubator/npanday/branches/npanday-1.4.x/dotnet/pom.xml
Propchange: incubator/npanday/branches/npanday-1.4.x/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Dec 20 09:21:21 2011
@@ -1,4 +1,4 @@
/incubator/npanday/branches/NPANDAY-410:1210743-1210765
/incubator/npanday/branches/npanday-uac-removed:1002005-1024539
/incubator/npanday/branches/npanday-vs2010-support:1002029-1025477
-/incubator/npanday/trunk:1221087,1221092,1221101,1221116-1221117
+/incubator/npanday/trunk:1221087,1221092,1221101,1221116-1221117,1221159
Modified: incubator/npanday/branches/npanday-1.4.x/dotnet/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/npanday/branches/npanday-1.4.x/dotnet/pom.xml?rev=1221161r1=1221160r2=1221161view=diff
==
--- incubator/npanday/branches/npanday-1.4.x/dotnet/pom.xml (original)
+++ incubator/npanday/branches/npanday-1.4.x/dotnet/pom.xml Tue Dec 20 09:21:21
2011
@@ -104,6 +104,11 @@ under the License.
groupIdorg.apache.npanday.plugins/groupId
artifactIdNPanday.Plugin.Settings.JavaBinding/artifactId
version${bootstrap.npanday.version}/version
+ configuration
+!-- Required until this can be done in Java, as otherwise there is
+ a bootstrapping problem trying to run the goal --
+skiptrue/skip
+ /configuration
/plugin
/plugins
/pluginManagement
[jira] [Updated] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible
[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen updated NPANDAY-499:
--
Description:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor)
was:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
1) (/) The configuration should be split up into multiple files
2) (/) Plugins should be able to contribute their own configurations (for
example: the test-plugin should specify where to find nunit; currently it is
specified in dotnet-core)
3) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
4) (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
5) Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
6) Rename 'plugin' to configuration for executable-plugins and compiler-plugins
7) Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
8) Join executable-plugins and compiler-plugins into one model (the latter
extending the latter)
9) Replace MutableCompilerConfiguration and MutableExectuableConfiguration with
compositions based on configurations / are pojos instructed from the outside now
10) ..
Make configuration for compiler-plugins and executable-plugins more flexible
Key: NPANDAY-499
URL: https://issues.apache.org/jira/browse/NPANDAY-499
Project: NPanday
Issue Type: Improvement
Components: Maven Plugins
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
Fix For: 1.5.0-incubating
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently
it is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if
probingPaths do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
[jira] [Updated] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible
[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen updated NPANDAY-499:
--
Description:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor; adds 'probingPaths' and 'executableVersion')
was:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor)
Make configuration for compiler-plugins and executable-plugins more flexible
Key: NPANDAY-499
URL: https://issues.apache.org/jira/browse/NPANDAY-499
Project: NPanday
Issue Type: Improvement
Components: Maven Plugins
Reporter: Lars Corneliussen
Assignee: Lars Corneliussen
Fix For: 1.5.0-incubating
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently
it is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if
probingPaths do not match, or a new version has not yet made it into NPanday)
h3.
[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
vendorNameMICROSOFT/vendorName
vendorVersion3.0/vendorVersion
frameworks
framework
frameworkVersion3.0/frameworkVersion
installRootC:\Windows\Microsoft.NET\Framework64\v3.0/installRoot
sdkInstallRootC:\Program Files\Microsoft.NET\SDK\v2.0
64bit\/sdkInstallRoot
executablePaths
executablePathC:\Windows\Microsoft.NET\Framework64\v2.0.50727/executablePath
executablePathC:\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
vendorNameMICROSOFT/vendorName
vendorVersion3.0/vendorVersion
frameworks
framework
!-- new !! --
frameworkArchitectureAMD64/frameworkArchitecture
frameworkVersion3.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)
--
!-- executableProbingPathC:\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:
[jira] [Resolved] (NPANDAY-490) Create integration test that verifies, that a msdeploy.zip-Artifact is attached
[ https://issues.apache.org/jira/browse/NPANDAY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen resolved NPANDAY-490. --- Resolution: Fixed Create integration test that verifies, that a msdeploy.zip-Artifact is attached --- Key: NPANDAY-490 URL: https://issues.apache.org/jira/browse/NPANDAY-490 Project: NPanday Issue Type: Technical task Components: Maven Plugins, Visual Studio Add-in Reporter: Lars Corneliussen Assignee: Lars Corneliussen Fix For: 1.5.0-incubating -- 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] [Created] (NPANDAY-506) Create azure-maven-plugin + CSPack base Mojo
Create azure-maven-plugin + CSPack base Mojo Key: NPANDAY-506 URL: https://issues.apache.org/jira/browse/NPANDAY-506 Project: NPanday Issue Type: Sub-task Components: Integration Tests Reporter: Lars Corneliussen Assignee: Lars Corneliussen Fix For: 1.5.0-incubating -- 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] [Resolved] (NPANDAY-494) Implement msdeploy-packaging goal that creates and attaches the package
[ https://issues.apache.org/jira/browse/NPANDAY-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen resolved NPANDAY-494. --- Resolution: Fixed Implement msdeploy-packaging goal that creates and attaches the package --- Key: NPANDAY-494 URL: https://issues.apache.org/jira/browse/NPANDAY-494 Project: NPanday Issue Type: Technical task Components: Maven Plugins, Visual Studio Add-in Reporter: Lars Corneliussen Assignee: Lars Corneliussen Fix For: 1.5.0-incubating -- 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] [Created] (NPANDAY-507) Create integration test that verifies that a cspkg is created and installed (including one WebRole)
Create integration test that verifies that a cspkg is created and installed (including one WebRole) --- Key: NPANDAY-507 URL: https://issues.apache.org/jira/browse/NPANDAY-507 Project: NPanday Issue Type: Sub-task Reporter: Lars Corneliussen Assignee: Lars Corneliussen -- 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] [Created] (NPANDAY-508) Make sure the Service-Configuration is attached (with classifier)
Make sure the Service-Configuration is attached (with classifier) - Key: NPANDAY-508 URL: https://issues.apache.org/jira/browse/NPANDAY-508 Project: NPanday Issue Type: Sub-task Reporter: Lars Corneliussen Assignee: Lars Corneliussen -- 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] [Updated] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible
[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen updated NPANDAY-499:
--
Description:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' to instead of 'profile' for locating the correct
executable-plugin; still allowing profile for customizing.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor; adds 'probingPaths' and 'executableVersion')
h3. Execution and Mojo Interaction
* Refactor ExecutableRequirement.ctor to accept VendorRequirment +
executableIdentifier, executableVersion and executableProfile.
* Remove get/setCommands() from ExecutableConfig, and require them to be passed
in to NetExecutable#execute() as parameter -
NetExecutable#execute(ListString commands) / filtering will happen inside
* Provide utility methods, that handle exception conversions for Mojos (wrap
PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
was:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
h3. Location of the right executable
* Use 'identifier' instead of 'profile' for locating the correct
executable-plugin.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor; adds 'probingPaths' and 'executableVersion')
Make configuration for compiler-plugins and executable-plugins more flexible
Key: NPANDAY-499
URL: https://issues.apache.org/jira/browse/NPANDAY-499
Project: NPanday
Issue Type: Improvement
Components: Maven Plugins
[jira] [Updated] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible
[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen updated NPANDAY-499:
--
Description:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
* It should be configurable per 'plugin' and overrideable through a Mojo param
/ project-level-property, whether or not NPanday should try to run the command
from the %PATH%
h3. Location of the right executable
* Use 'identifier' to instead of 'profile' for locating the correct
executable-plugin; still allowing profile for customizing.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Rename 'vendor' and 'vendorVersion' to 'frameworkVendor' and
'frameworkVendorVersion' for better clarity (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
** *ThirdpartyExecutable* (is provided by a third party, hence neither NPanday
nor the vendor; adds 'probingPaths' and 'executableVersion')
h3. Execution and Mojo Interaction
* Refactor ExecutableRequirement.ctor to accept VendorRequirment +
executableIdentifier, executableVersion and executableProfile.
* Remove get/setCommands() from ExecutableConfig, and require them to be passed
in to NetExecutable#execute() as parameter -
NetExecutable#execute(ListString commands) / filtering will happen inside
* Provide utility methods, that handle exception conversions for Mojos (wrap
PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
was:
Currently all configuration for compiler-plugins and executable-plugins are
located centrally in {{dotnet-core/main/resources/META-INF/npanday/*.xml}}.
h3. Design
* (/) Plugins should be able to contribute their own configurations
(for example: the test-plugin should specify where to find nunit; currently it
is specified in dotnet-core)
* Mojos should accept additional configurations as parameters (if probingPaths
do not match, or a new version has not yet made it into NPanday)
* It should be configurable per 'plugin' and overrideable through a Mojo param
/ project-level-property, whether or not NPanday should try to run the command
from the %PATH%
h3. Location of the right executable
* Use 'identifier' to instead of 'profile' for locating the correct
executable-plugin; still allowing profile for customizing.
* Enable version ranges for matching of versions in executables and compilers
for vendorVersion, frameworkVersion and executableVersion(to come) {{[1.1,)}]
or {{[2.0,3.0)}}
* (/) It should be possible to configure executableVersion additionally to
vendorVersion and frameworkVersion (for example in order to locate path's for
Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
h3. Path detection
* (/) Enable filtering in configuration files, supporting Windows Registry,
Environment Variables and (!) project properties
h3. Naming and overall structure
* (/) (A) Mojo comes with *Requirement and *Config, (B) Repository delivers
*Capability which is based on *Plugins; Then we try to match (A) with (B).
* Rebrand 'plugin' to 'capability-configuration', hence
CompilerExecutableCapabilityConfiguration (?)
* Join executable-plugins and compiler-plugins into one model (MDO + base
classes for Capability
* distinguish three types of executables:
** *VendorExecutable* (is provided by the framework vendor
** *CompilerExecutable* (is also provided by the framwork vendor, but has some
extra requirements/capabilities
**
svn commit: r1221460 - in /incubator/npanday/trunk/components: dotnet-executable/src/main/java/npanday/executable/ dotnet-executable/src/main/java/npanday/executable/impl/ dotnet-model/executable-plug
Author: lcorneliussen
Date: Tue Dec 20 19:48:23 2011
New Revision: 1221460
URL: http://svn.apache.org/viewvc?rev=1221460view=rev
Log:
[NPANDAY-499] Make configuration for compiler-plugins and executable-plugins
more flexible
o Added executableVersion to exectuable plugins
Modified:
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableCapability.java
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableRequirement.java
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/impl/CapabilityMatcherImpl.java
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/impl/MatchPolicyFactory.java
incubator/npanday/trunk/components/dotnet-model/executable-plugins/executable-plugins.mdo
incubator/npanday/trunk/components/dotnet-model/executable-plugins/src/test/groovy/npanday/model/compiler/plugins/io/ExecutablePluginXpp3ReaderTest.groovy
incubator/npanday/trunk/components/dotnet-model/executable-plugins/src/test/resources/sample-executable-plugins.xml
Modified:
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableCapability.java
URL:
http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableCapability.java?rev=1221460r1=1221459r2=1221460view=diff
==
---
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableCapability.java
(original)
+++
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableCapability.java
Tue Dec 20 19:48:23 2011
@@ -96,6 +96,11 @@ public interface ExecutableCapability
String getExecutableName();
/**
+ * Returns the version of the executable that is offered as capability.
+ */
+String getExecutableVersion();
+
+/**
* Returns the class name of the executable plugin that knows how to
handle the execution request.
*
* @return the class name of the executable plugin that knows how to
handle the execution request
Modified:
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableRequirement.java
URL:
http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableRequirement.java?rev=1221460r1=1221459r2=1221460view=diff
==
---
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableRequirement.java
(original)
+++
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/ExecutableRequirement.java
Tue Dec 20 19:48:23 2011
@@ -26,7 +26,6 @@ import npanday.vendor.VendorRequirement;
*
* @author Shane Isbell
* @author a href=mailto:lcornelius...@apache.org;Lars Corneliussen/a
- *
* @see ExecutableCapability
* @see CapabilityMatcher
*/
@@ -36,16 +35,32 @@ public class ExecutableRequirement
private String profile;
+private String executableVersion;
+
public ExecutableRequirement( String vendorName, String vendorVersion,
String frameworkVersion, String profile )
{
+this( vendorName, vendorVersion, frameworkVersion, profile, null );
+}
+
+public ExecutableRequirement(
+String vendorName, String vendorVersion, String frameworkVersion,
String profile, String executableVersion )
+{
super( vendorName, vendorVersion, frameworkVersion );
this.profile = profile;
+this.executableVersion = executableVersion;
}
public ExecutableRequirement( Vendor vendor, String vendorVersion, String
frameworkVersion, String profile )
{
+this( vendor, vendorVersion, frameworkVersion, profile, null );
+}
+
+public ExecutableRequirement(
+Vendor vendor, String vendorVersion, String frameworkVersion, String
profile, String executableVersion )
+{
super( vendor, vendorVersion, frameworkVersion );
this.profile = profile;
+this.executableVersion = executableVersion;
}
public String getProfile()
@@ -53,8 +68,8 @@ public class ExecutableRequirement
return profile;
}
-public void setProfile( String profile )
+public String getExecutableVersion()
{
-this.profile = profile;
+return executableVersion;
}
}
Modified:
incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/impl/CapabilityMatcherImpl.java
URL:
http://svn.apache.org/viewvc/incubator/npanday/trunk/components/dotnet-executable/src/main/java/npanday/executable/impl/CapabilityMatcherImpl.java?rev=1221460r1=1221459r2=1221460view=diff
