Le mar. 2 janv. 2024 à 18:46, Martin Desruisseaux < [email protected]> a écrit :
> Hello Romain > > Le 2024-01-02 à 18 h 16, Romain Manni-Bucau a écrit : > > > 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. > > > The proposed replacement is not as rigid, because it is controlled by > dependency properties, which are themselves controlled by artifact > types. RMB: so you mean you don't intend to link the classpath to the type? this is what is rigid, assuming all the toggles you spoke about (let's focus on jpms for now) are shared by plugins, this is not the case, javadoc, surefire and compiler don't share them most of the time - it is the same for exports/opens in another JVM area. > Furthermore, the proposal does not solve rare cases. I believe it > solves the vast majority of JPMS cases. RMB: Probably the majority, not sure it is vast or just most of cases (60% or 90%? tempted to say something around 70 from the projects I saw but didn't see much simple JPMS libs for now so can be higher). But in these "majority" how many projects built with maven is it? Probably very few. And this is a key point, this classpath definition is needed for any project, not only JPMS, and this solution is specific to JPMS since it ignores most of plugins outside java ecosystem, so we miss the refactoring goal IMHO and still need to rework that area from scratch - until you manage to do both of your PR without any change to maven core nor plugin which would proove it works. > For demonstrating my point, I > wrote two test cases with extensive explanations months ago showing why > Maven 3 doesn't work with JPMS [1][2]. If you believe that Maven 4 with > the proposed improvements would still not work, I propose that we still > create a prototype, so you can create a test case demonstrating why the > prototype doesn't work. For now, the arguments that I have seen against > the proposal were either proposing to use Maven like Ant (declare the > paths ourselves in <compilerArgs>), or were asking for troubles (not > encouraging consistency between javac, java, javadoc, etc. tools). > > [1]https://github.com/Geomatys/MavenModulepathBug > [2]https://github.com/Geomatys/MavenModulepathBug/tree/cyclic-graph > > > > 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 > > > The fact that types may be like scope in not specific to JPMS. RMB: You are perfectly right but this is wrong too and we shouldn't encourage that since it already creates confusion for end users and messes up builds - plus it does not solve the issue to define custom ones without coding for now. > This is > why I asked for clarification in my previous email. I leave the decision > to core Maven developers, and will adapt the proposal as needed. From > JPMS perspective, as long as DependencyProperties is populated with the > information that I need, no matter if the information come from Type or > elsewhere, this is fine. > > > > 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 > > > JPMS is core to Java, so I think it should be core to Maven too. RMB: annotation processor is core to java since 20 years, never been core to any build tool even if widely used so for me it is 100% about the usage and adoption/consumer need. For now we get very low requests for JPMS - and projects are not blocked in current status. That said, once again, I have no big issue with supporting better JPMS, my main concern is supporting it specifically in the core - which ideally shouldn't have much specific integration, even classpath is historical more than anything else - and not solution the underlying issue. > All > standard Java tools to my knowledge handle JPMS in a consistent way, > with the same options when they apply. RMB: the interface is almost the same for all, ack...does not mean they will consume the same artifacts for all these options as mentionned so you still need one option per tool so will you create a type=javadoc-module-path, type=javac-module-path etc and all of them inheriting by default of type=module-path? How would you merge them? Wouldn't it be saner to just let the user compose the dependencies or something equivalent? A very interesting thing is that, depending the option chosen it can drop the scope notion (if you can affect a set of deps to a plugin you don't need scope anymore, just default set names per lifecycle). > So I believe they are as > fundamental as the classpath. RMB: yes but it doesn't change much things, classpath is not a real concept in maven core, it is a legacy method and plugins always surface it with other collection rules (scopes is one, explicit filter another one) so I guess it is more that fundamentally we don't have any path in core but only plugin paths. > But anyway, as said above, for making > progress, I propose to go ahead with a prototype first, then demonstrate > the prototype shortcoming with test cases. > RMB: We already went this path - don't recall it was on jira - but we already saw that current design is very specific. While it could fit a plugin it looks very surprising to hit core for me, even if you are totally right, some legacy makes it looking like it could have fit sadly :(. > > Martin > >
