marking a plugin parameter as read-only is a choice of the plugin developer, who does not consider configuration as a provided plugin/goal feature, but wants to inject default values that are consistent with other POM configuration
if you think the plugin needs to be improved to be more flexible, convince the plugin maintainer, help him by providing a good documentation of the new feature in a PR and for reference, here is the Maven core bug that will be fixed in 3.7.0: https://issues.apache.org/jira/browse/MNG-5001 Given that bug, people took the habit of overriding values of parameters that were expected to be read-only (lately I discovered that some IDEs proposed as hints such normally invalid parameters, which helped developers discover these parameters that were intentionally not shown in plugin documentation...): by re-checking what should never have been allowed, perhaps such discussions of updating some plugins to permit more flexible configuration will happen in the future... we absolutely need to fix the core bug and push eventual discussions of parameter that should not be read-only or provide some mean of additional configuration at the right level = plugin level Regards, Hervé Le jeudi 23 avril 2020, 21:15:19 CEST Enrico Olivelli a écrit : > Javier, > In upcoming Maven release 3.7 > 0 it won't be allowed to overwrite readonly attributes. > > I am sorry, I don't know how to fix your issue. > > Question for the community: can we drop the 'readonly' flag from the > 'resources' field of checkstyle plugin? > > I mean, it has always been writable up to now, so if we don't want to break > existing poms we should make it explicitly non readonly. > Is there any problem with this approach? > > I image that we will do this way for other falsely readonly property > > Enrico > > Il Gio 23 Apr 2020, 20:06 Javier Gómez <javier.go...@prefapp.es> ha scritto: > > Hi, > > > > we are testing a config, that overwrites a readonly attribute, in Maven > > Checkstyle plugin config, to be able to analyze a set of resource > > folders in project root folder. > > > > We don't want to define this spefic folders config in POM build > > <resources> block, to avoid inherit that in child POMs, so we are > > forcing that at the plugin level, specifying the <resources> block > > attribute. > > > > That this is a read-only attribute, and we define it in the plugin > > configuration, does not imply that the compilation fails, as I would > > expect. Is that correct? > > > > Any side effect that we could expect of this configuration? > > > > Thanks in advance. > > > > > > ======= > > > > # Directory structure layout: > > > > /module1 > > > > src/main/java > > src/main/resources > > pom.xml > > > > /module2 > > > > ... > > > > /src > > /dir1 > > /dir2 > > pom.xml > > > > # > > # Parent POM build config > > # > > > > <build> > > > > <pluginManagement> > > > > [Checkstyle config] > > > > </pluginManagement> > > > > <plugin> > > > > # config to analyze the specific resources folders, in project > > > > root folder > > > > <groupId>org.apache.maven.plugins</groupId> > > <artifactId>maven-checkstyle-plugin</artifactId> > > > > <inherited>false</inherited> > > <configuration> > > > > <resources> > > > > <resource> > > > > <directory>dir1</directory> > > > > </resource> > > <resource> > > > > <directory>dir2</directory> > > > > </resource> > > > > </resources> > > > > </configuration> > > > > </plugin> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
