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/01 16:30:40 UTC
[jira] [Created] (NPANDAY-499) Make configuration for
compiler-plugins and executable-plugins more flexible
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
Reporter: Lars Corneliussen
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)
h2. The plan
- use {{org.apache.maven.shared.io.location.LocatorStrategy}} to find all relevant configs
- then merge them
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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. 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')
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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(List<String> 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
> 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' 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(List<String> commands) / filtering will happen inside
> * Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Corneliussen updated NPANDAY-499:
--------------------------------------
Component/s: Maven Plugins
Fix Version/s: 1.5.0-incubating
Assignee: Lars Corneliussen
> 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}}.
> 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)
> h2. The plan
> - use {{org.apache.maven.shared.io.location.LocatorStrategy}} to find all relevant configs
> - then merge them
--
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] [Work started] (NPANDAY-499) Make configuration for
compiler-plugins and executable-plugins more flexible
Posted by "Lars Corneliussen (Work started) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on NPANDAY-499 started by Lars Corneliussen.
> 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}}.
> 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)
> h2. The plan
> - use {{org.apache.maven.shared.io.location.LocatorStrategy}} to find all relevant configs
> - then merge them
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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(List<String> 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
** *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(List<String> commands) / filtering will happen inside
* Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
> 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)
> * 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(List<String> commands) / filtering will happen inside
> * Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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}}.
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)
h2. The plan
- use -{{org.apache.maven.shared.io.location.LocatorStrategy}}- Google Code Reflections to find all relevant configs: http://code.google.com/p/reflections/wiki/UseCases
- then merge them
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)
h2. The plan
- use {{org.apache.maven.shared.io.location.LocatorStrategy}} to find all relevant configs
- then merge them
> 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}}.
> 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)
> h2. The plan
> - use -{{org.apache.maven.shared.io.location.LocatorStrategy}}- Google Code Reflections to find all relevant configs: http://code.google.com/p/reflections/wiki/UseCases
> - then merge them
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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 (?)
* 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(List<String> 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' 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(List<String> commands) / filtering will happen inside
* Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
> 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)
> * 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
> ** *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(List<String> commands) / filtering will happen inside
> * Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Corneliussen updated NPANDAY-499:
--------------------------------------
Fix Version/s: (was: 1.5.0-incubating)
Backlog
> 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: Backlog
>
>
> 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(List<String> commands) / filtering will happen inside
> * Provide utility methods, that handle exception conversions for Mojos (wrap PlatformUnsupportedException and ExecutionException) in MojoExecutionExceptions
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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}}.
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) ..
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 executable-versions additionally to vendor- and framework-versions (for example in order to locate path's for Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
> 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}}.
> 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) ..
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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
> * (/) 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)
--
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
Posted by "Lars Corneliussen (Updated) (JIRA)" <ji...@apache.org>.
[ 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}}.
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 executable-versions additionally to vendor- and framework-versions (for example in order to locate path's for Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
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)
h2. The plan
- use -{{org.apache.maven.shared.io.location.LocatorStrategy}}- Google Code Reflections to find all relevant configs: http://code.google.com/p/reflections/wiki/UseCases
- then merge them
> 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}}.
> 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 executable-versions additionally to vendor- and framework-versions (for example in order to locate path's for Azure Tools 1.6 specifically, but only when on MICROSOFT 4.0+ and Windows.
--
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