[
https://issues.apache.org/jira/browse/MJAR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843091#comment-16843091
]
Hervé Boutemy edited comment on MJAR-264 at 5/18/19 5:40 AM:
-------------------------------------------------------------
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
was (Author: hboutemy):
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
> 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)
