Hmm, I still think it is an abuse to think that, javadoc is a good example which, except the location, often override the rest of options.
That said the point is more that if we go with generic groups of dependencies we should go with generic source sets and enable to attach them attributes, not attributes specific to some plugins (which are not even the majority of a build nowdays) and just standardize their usages in our built-in plugins no? Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Le lun. 24 mars 2025 à 20:42, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2025-03-24 à 20 h 32, Romain Manni-Bucau a écrit : > > > any reason to move a plugin configuration from plugin to <sources>? > > (concretely why do we go that way instead of dropping sources concept > > from build)? > > > Because that configuration is used by many plugins. The same information > is needed by Javadoc plugin, by resource plugin (for deciding if a > resource must be copied under META-INF/versions/), and maybe other that > I'm forgetting. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
