[MJAR-264] finalName property can be set and is not immutable

[jira-importer]

Stephane Nicoll opened MJAR-264 and commented

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!

 

 

---

Affects: 3.1.1

Issue Links:

• MNG-5001 @readonly Mojo parameter annotation doesn't work any more
  ("is fixed by")
• MJAR-217 Make finalName readonly parameter

2 votes, 7 watchers

[jira-importer]

Robert Scholte commented

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.

[jira-importer]

Hervé Boutemy commented

do you know about MNG-5001?
Is it in your case a mutability of a plugin parameter or really the non-default value of projact.build.finalName

[jira-importer]

Stephane Nicoll commented

This is not about the fact the field is not effectively read-only but rather that its default value is lazily resolved. Given that the field is supposed to be read-only, the default in the annotation basically means the value we should use. The problem with this arrangement (besides the field can actually be set) is that its value is resolved once the plugin executes. 

 

In other words, if you have an expression as in the attached project, MavenProject#getBuild().getFinalName() does not return the same thing.

[jira-importer]

Hervé Boutemy commented

sorry, I don't understand.
Ok, in your example pom, the value of POM project.build.finalName is overriden https://github.com/snicoll-scratches/test-jar-final-name/blob/master/pom.xml#L17
then replaces the value from super pom: https://maven.apache.org/ref/3.6.1/maven-model-builder/super-pom.html

but:

1. I don't know why you tell this should not be permitted (even if the value chosen in your example is not a good idea, and I don't know if there is really a good value other than the default one from super-pom)
2. but more importantly: the value is not muted once the effective POM is build, then every plugin referencing ${project.build.finalName} will get the same result

Making plugin finalName parameter read only with value ${project.build.finalName} means that the plugin will follow whatever the name is defined in the effective pom: this will ensure every file attached to the gav will have the same prefix name

It's not really about "immutability" at runtime, but consistent value for every packaging file created by plugins (by removing customization feature)

I confess that perhaps Maven core should not not permit people to override project.build.finalName in their pom.xml, since the default value is so critical as a convention for the repository format: but this is another feature request, more at MNG level

I don't know Spring Boot Maven Plugin, and how the resulting archive is used: perhaps this plugin does not really have the same objective than packaging plugins that create archives that are consumed as dependencies in the reactor or as attachments to the GAV to go into the repository

[jira-importer]

John commented

Since you are working on finalName, should issue https://issues.apache.org/jira/browse/NETBEANS-2976 be moved to this project so it gets attention?