[jira] [Assigned] (NPANDAY-499) Make configuration for compiler-plugins and executable-plugins more flexible

["Lars Corneliussen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Corneliussen reassigned NPANDAY-499:
-----------------------------------------

    Assignee: Brett Porter  (was: 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: Brett Porter
>             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 was sent by Atlassian JIRA
(v6.2#6252)