[
https://issues.apache.org/jira/browse/NPANDAY-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter resolved NPANDAY-499.
----------------------------------
Resolution: Fixed
Fix Version/s: (was: Backlog)
1.5.0-incubating
Assignee: Lars Corneliussen (was: Brett Porter)
Marking fixed with the work done to date.
Agree there are more improvements that could be made here - there is an awful
lot of cut and paste needed to provide new versions that don't have big
differences, and no smarts about how the frameworks build up. It'd be good for
the framework to be able to pick up on the tools version and visual studio
version where applicable. We can defer those to other issues though.
> 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 was sent by Atlassian JIRA
(v6.2#6252)
