[ 
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182858#comment-17182858
 ] 

Falko Modler edited comment on MNG-5897 at 8/23/20, 9:41 PM:
-------------------------------------------------------------

Better configuration support for extensions would be very much appreciated!

I am maintaining https://github.com/vackosar/gitflow-incremental-builder (GIB) 
and I just recently added a "fake" plugin/mojo to expose the many properties 
(and their descriptions) in an IDE and help-plugin friendly way.
This comes at the price of either maintaining the properties twice manually or 
at the price of added complexity for generating the plugin parameters (see 
[MojoParametersGeneratingByteBuddyPlugin|https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo/MojoParametersGeneratingByteBuddyPlugin.java]).

It would be really great if (with the proposed solution) extension parameters 
and their descriptions would be picked up by IDEs and the help-plugin.

Another approach might be to enhance the plugin + extension hybrid setup (like 
GIB is using) to have {{@Parameter}} (or something else) recognized on non-mojo 
classes.

Btw: The downside of {{.mvn/extensions.xml}} is that you cannot use profiles 
there and I am not sure whether tools like GitHub Dependabot will pick up such 
extensions (defined outside of {{pom.xml}}).


was (Author: famod):
Better configuration support for extensions would be very much appreciated!

I am maintaining https://github.com/vackosar/gitflow-incremental-builder (GIB) 
and I just recently added a "fake" plugin/mojo to expose the many properties 
(and their descriptions) in an IDE and help-plugin friendly way.
This comes at the price of either maintaining the properties twice manually or 
at the price of added complexity for generating the plugin parameters (see 
[MojoParametersGeneratingByteBuddyPlugin|https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo/MojoParametersGeneratingByteBuddyPlugin.java]).

It would be really great if (with the proposed solution) extension parameters 
and their descriptions would be picked up by IDEs and the help-plugin.

Another approach might be to enhance the plugin + extension hybrid setup (like 
GIB is using) to have `@Parameter` (or something else) recognized on non-mojo 
classes.

Btw: The downside of {{.mvn/extensions.xml}} is that you cannot use profiles 
there and I am not sure whether tools like GitHub Dependabot will pick up such 
extensions (defined outside of {{pom.xml}}).

> Make extensions configurable in a more convenient way.
> ------------------------------------------------------
>
>                 Key: MNG-5897
>                 URL: https://issues.apache.org/jira/browse/MNG-5897
>             Project: Maven
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 3.3.3
>            Reporter: Karl Heinz Marbaise
>            Priority: Major
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}} 
> to load it. 
> But at the moment the only possibility to configure your extensions (or 
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in 
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> <extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>   <extension>
>     <groupId/>
>     <artifactId/>
>     <version/>
>     <configuration>
>      <parameter>...</parameter>
>    </configuration>
>   </extension>
> </extensions>
> {code}
> with some kind of replacements like in the pom.xml file (like 
> {{$\{project.basedir}}} etc.) ? 
> This could make the usage of extensions much more convenient...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to