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

**[Stephane Nicoll](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=snicoll)** opened **[MJAR-264](https://issues.apache.org/jira/browse/MJAR-264?redirect=false)** 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](https://issues.apache.org/jira/browse/MNG-5001) `@readonly` Mojo parameter annotation doesn't work any more
(_**"is fixed by"**_)
- [MJAR-217](https://issues.apache.org/jira/browse/MJAR-217) Make finalName readonly parameter

2 votes, 7 watchers

Start with the reproducer at https://github.com/snicoll-scratches/test-jar-final-name, then read MNG-5001 and MJAR-217 for the intended readonly behavior. Confirm how finalName can be set and change lazily during a build; done means the plugin behavior and compatibility decision are consistent with Maven core plugins.

Written by the indexing model from the issue text.