[
https://issues.apache.org/jira/browse/MJAR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837196#comment-16837196
]
Robert Scholte commented on MJAR-264:
-------------------------------------
First let's explain why we are removing the final-name option from most
packaging plugins:
To make any artifact available as part of the reactor, the file must be bound
to its MavenProject instance. This is done by the packaging plugins, such as
the maven-jar-plugin. The downside of this if a module is a dependency for
another project its packaging goal must always be called even when nothing has
changed (otherwise the jar won't be bound).
This can be improved if we have a predictable filename for the (to be) bound
artifacts without going through all plugin execution blocks. By default it'll
based on the artifactId + version + type and optional classifier. In some cases
you want to control the filename, e.g. for versionless execution of jars. By
using the project.build.finalName we can have best of both worlds.
Packaging plugins may decide to provide a parameter for finalName, but such
file won't be reachable by other Maven modules without the explicit call of the
goal (since that one is responsible for binding the jars to its MavenProject
instance)
So these are plugin preparations that will help getting better user experience
of Maven in a future release.
> finalName property can be set and is not immutable
> --------------------------------------------------
>
> Key: MJAR-264
> URL: https://issues.apache.org/jira/browse/MJAR-264
> Project: Maven JAR Plugin
> Issue Type: Bug
> Affects Versions: 3.1.1
> Reporter: Stephane Nicoll
> Priority: Major
>
> From what I understood, the intention of making sure the {{finalName}} is
> read-only was to prevent users to be able to mutate its value while the build
> was running. Rather, they should use the standard {{build/finalName}} that is
> immutable.
> Unfortunately, both these are happening at the moment. There is a bug so that
> {{read-only}} is ignored and the field can be set anyway. And because the
> field as a default to the standard property, its value is evaluated lazily
> and can change based on the execution of another plugin.
> Here is a simple project that reproduces the problem with the latest version
> of the plugin: [https://github.com/snicoll-scratches/test-jar-final-name]
> The Spring Boot Maven Plugin has the exact same setup (actually we did align
> our plugin to what the jar plugin did for consistency). We broke users by
> removing the field when we noticed one can still set it and we are looking
> for advices as what to do. We want to make sure that the decision we take is
> align with the direction of core plugins.
> Thanks!
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
