Le mer. 3 janv. 2024 à 19:25, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit : > > > see it as "where classpath is in core comes from the time maven was > > only for java libs" (i'd say maven 2 cause I don't know maven 1). > > > The CLASSPATH_CONSTITUENT property and related isAddedToClasspath() > methods were added in Maven 4. I let you (Maven core developers) choose > where to put those properties/methods. My point is that everywhere there > is non-deprecated class-path, should be module-path too. > I understood but the assumption that what is not deprecated is an example is something I wouldn't risk to bet on so maybe better to be in the mindset "what looks correct" (just my 2 cts). > > > > From what I understood it uses the getpathtype methods of your PR and > > limits the type to CLASSES or MODULE, this is where I'm a bit lost. > > > This is a limitation of the current version of DependencyProperties, > because it uses boolean flags for specifying whether a dependency should > be on the CLASSES set or the MODULES set. So we are limited by the > predefined set of boolean flags. This is why I proposed to replace them > by a single property giving directly the PathType values. This is a > minor change, but maybe I should add a commit for that change now for > clarity. > Ok, so it does not work as this but you explained the proposal in a few iterations, got it now, thanks, was starting to be lost! > > > > A lib consumed both as a class path element or module path element > > (most libs) generally compiles using classpath and renders the javadoc > > with module > > > I'm not sure what you mean. Class-path / module-path apply to the > dependencies, not to the module that we are compiling (unless you are > talking about Module Source Hierarchy, but this is another topic). If > you mean that libs generally compile with their dependencies on the > class-path, this is not true if for JPMS module. To prove my point, I > have created yet another test case: > > https://github.com/Geomatys/MavenModulepathBug/tree/modularized-client > > See instruction in the readme. Can you compile this test case with the > dependency on the class-path, without omitting the module-info in the > compilation? > This is exactly the case, module-info is injected somehow - a common case is by generating its bytecode but multiple compiler executions is another case. Now, enhance your example to consume a jar where implicit module name would be invalid for example, how would you compile? That said it is also true this is not a big deal which dispatching works as before probably and the configuration of dependencies can still be done per plugin (javadoc rendering modules and compilation being done on classpath even with 2 passes). > > > > Today javadoc plugin compensate that by *not* respecting the pom > > configuration (it has yet another "guess" algorithm which works not > > bad) but your wish is to drop that so all the current functional cases > > would be broken or you would have to keep what you don't want in the > > plugin > > > If you are talking about javadoc:aggregate, indeed I would not touch > that part. This particular case lives in its own world. But > javadoc:javadoc would work in the same way as java, javac and all other > standard tools. > javadoc:javadoc -> https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L4420 > > Martin > >
