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

ASF GitHub Bot commented on MPLUGIN-450:
----------------------------------------

rmannibucau commented on PR #240:
URL: 
https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891626872

   > I don't mix anything, but that's actually the point, now the producer is 
forced to set something so it stays as before, because consumers before have 
never complained obviously that they want some change.
   
   I don't understand what you mean, I read it like "because [consumers] are 
not impacted they would have to be impacted", so not sure the point.
   The key in what you said is _now the producer is forced to set something so 
it stays as before_ which is exactly that, keep in mind part of the producers 
were not controlling at all that part and another part were setting invalid 
values so overall validating it the hard way is the safest solution for maven 
and we keep backward compatibility for consumers by explaining the producer to 
set the goal prefix so nobody is broken.
   
   > So neither producer nor consumer requested for such feature / change
   
   Isn't it always the case when there was a design issue in a tool and it gets 
fixed? Nobody asked to configure a filter for RMI serialization, it is the same 
there.
   
   > e.g. for the tycho case I now need to add 24 useless duplication in the 
config that was previously perfectly derived without a problem and users never 
where unhappy enough to open an issue > 10 years:
   
   on the user point please see previous comment, it is *normal* they never 
complained since this fix does *not* impact them
   
   > https://github.com/eclipse-tycho/tycho/pull/3363/files
   
   Looks good and now you control your produced plugin and you will not break 
your command lines (ci) even if you refactor your gav to comply to maven 
recommended pattern (x-maven-plugin, not x-plugin), this sounds way better to 
me.




> Make goal prefix mandatory by default
> -------------------------------------
>
>                 Key: MPLUGIN-450
>                 URL: https://issues.apache.org/jira/browse/MPLUGIN-450
>             Project: Maven Plugin Tools
>          Issue Type: Improvement
>          Components: Plugin Plugin
>            Reporter: Tamas Cservenak
>            Assignee: Guillaume Nodet
>            Priority: Major
>             Fix For: 3.11.0
>
>
> The goal prefix currently is not mandatory, and plugin uses heuristic to 
> figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for 
> org.apache.maven plugins ONLY).
> In general, goal prefix is optional, but "good to have", and usually is 
> present.
> Cases when is not present, is when heuristics fails (so plugin module is not 
> named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide 
> one either. The cases when prefix is not present is mostly unintentional, but 
> maven-plugin-plugin leaves this without any remark or warning.
> IMHO, the maven-plugin-plugin should either warn, or even fail the build in 
> case when goal prefix is not present, but we may want to have some option to 
> turn off this feature (for me unknown reasons, where it would be expected to 
> NOT have goal prefix for a reason).
> TL;DR Am pretty much sure that in most of the cases when plugin developer 
> ends up with plugin without prefix, that it was unintentional (and causes 
> surprise later, not to mention refactoring the module name or POM change to 
> configure it), while there MAY be cases where goal prefix is not desired for 
> some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, 
> the out of the box defaults should enforce presence of it, while advanced 
> users still can produce prefix-less plugins with some extra configuration. 
> This would make things more explicit as well: even if plugin is named as 
> xxx-maven-plugin, configuration would be clear I do not want prefix for it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to