Le mer. 3 janv. 2024 à 17:03, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 16 h 45, Romain Manni-Bucau a écrit : > > maven4 introduces the notion of "services" (...snip...) So guess all > > is there to do it and core can stay as this for backward compat > > (maven4 must support maven3) but nothing more. > > Current services are class-path aware, with DependencyProperties and > isAddedToClasspath() methods. My argument is that where class-path is > handled, module-path should be handled too, because it is a replacement > for class-path. > No, I don't think this is a valid assumption, 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). But it is mainly a location issue IMHO, way less important than the concept point for me. > > > > Maybe I misread your PR but I didn't see where dependencies were added > > in dep resolver using the meta > > > I do not touch to this part of Maven. > >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. > > > > > use javadoc:javadoc then, intent is to run it with --module-path > > target/classes but compile with --classpath > > > No, if the project is compiled with --module-path, it should be run with > the same --module-path (except for JAR added/removed because of scopes), > and javadoc should be run with the same --module-path as well. No, this is your case which is part of the game only. 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 to expose all it can (and since the module meta can be ignored by the user more easily if he picks classpath rather than the opposite where the module meta would miss). > I do not > understand why you insist for inconsistent options? Can you please > provide a test case showing your point? We are keep arguing again and > again in circles. Please prove me your point with an "hello world" > compilable, executable and documentable on the command line with > inconsistent options, and showing that those inconsistencies are > required for producing the desired result. > 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 so I don't see where your alignment goes, it stops quite quickly for ~half of the cases? This can be done with types - your current options, just need to drop most of the path code from the pr, let plugin consumers types as path configuration (example for exec plugin: <classpath/> -> <classpath types="jar,foo,bar"/>) and it would work. It will just not be very neat and convenient in some builds cause you cant say dummy=foo+bar and use dummy in plugins but guess it is workable, just wonder how long this design will last before we start to work it around which is what makes me a be worried about the future of this design even if it works for your particular case. > > Martin > >
