Hi Martin, Think this propagate current lock situation where you only work in a particular subset of builds so I still think we should extract getDispatchedPaths , PathType etc to something like maven-shared (or nothing) and just make this logic owned by plugins, this is the only location it makes sense since it is the only location resolution is interpreted. In other words you deprecated isAddedToClasspath cause it was too rigid to put in place something as rigid which enables one rare (today) case so I'm not very enthusiatic about it.
Also, the fact that some types are now almost scopes also converges to the "make the plugin own its paths interpretation" cause from a maven core standpoint it looks wrong to mix both concepts (agents for ex are in a weird space - why using types was not great IMHO). Lastly design leads to weird cases like agents, processors etc which are ambiguous (it is not rare to have them differring between plugins - thinking to surefire, container "run" plugin, packaging plugin - jib - and runtime). So overall I'm quite mixed and still have a hard time to see it going anywhere else than a jpms extension which could sit outside maven to preconfigure the plugins but not as a generic feature widely *re*usable (and to be transparent I think enabling user to configure its dependency sets and let plugins consume it sounds like the least worse design - a bit like gradle configurations, happy to get alternative proposal, just dont seeing it yet). Best, Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 2 janv. 2024 à 17:53, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-02 à 17 h 44, Martin Desruisseaux a écrit : > > (…snip…) First, the (class, module, etc.)-paths, later the source > > directories (I wish Maven supports Module Source Hierarchy), in which > > case I will try to address multi-releases in same time. > > Actually, I have been silent on this topic in my description (for > avoiding to add a second debate to the first one), but the proposal is > already anticipating Module Source Hierarchy. It can been seen from the > fact that the getModuleNames() method returns a collection. In the worst > case (if supporting Module Source Hierarchy in Maven is not accepted), > the collection will always be a singleton or empty. And if Module Source > Hierarchy become accepted in the future, the proposed code is already > ready for that. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
