[
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
