Thank you very much for confirming Hervé. It would be nice if we had a way to identify that the value was set and then take an appropriate action in a custom plugin forthe time being.
Has anybody done that to workaround the issue maybe? On Fri, Apr 5, 2019 at 8:21 AM Hervé BOUTEMY <[email protected]> wrote: > sadly nothing: this is a known limitation in Maven 3 (that did not exist > in > Maven 2) > https://issues.apache.org/jira/browse/MNG-5001 > > I never had time to dig precisely into source code to see how hard the fix > would be. What I know is that when the fix will be available, we'll > probably > need a grace period with warnings for people setting such read-only > parameters > before really breaking such abnormal builds > > Regards, > > Hervé > > Le jeudi 4 avril 2019, 13:22:17 CEST Stephane Nicoll a écrit : > > Hey, > > > > I have a weird case trying to deprecate a "finalName" property where said > > property can still be set by the user. > > > > Here is the definition: > > > > /** > > * Name of the generated archive. > > * @since 1.0 > > */ > > @Parameter(defaultValue = "${project.build.finalName}", readonly = true) > > private String finalName; > > > > That property can be set when configuring the plugin and its value is > > injected. > > > > What am I missing? > > > > Thanks, > > S. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
