[ 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