Howdy, Romain, I don't get it fully: why would you put the same lib once on classpath (compiler), once on modulepath (javadoc) and once "resolved for tests"? Am not interested WHY would one do it today (as today people are "hacking the system", and it may happen due maven 3, plexus-java trickery, etc as they have no control), but why would one do something like that?
On Tue, Dec 19, 2023 at 6:08 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > I fully understand that but my point - same as last time - is that > "modular-jar" does not give you the information you want, ie "classpath for > compiler, module for javadoc, resolved for tests" for example. You totally > miss the configurable part of the command line and you are basically iso > maven 3 in terms of features, you just expanded the dictionnary to delay a > bit the moment the issues pop out but you didn't solve them so it is really > about defining sets of dependencies and making it configurable or doing > nothing IMHO. Using type is nasty for me by design but would work until it > is not hardcoded in maven core. > Defaults are just about convention, not capabilities. > > If the solution for you is "Plugins would not be forced to use the proposed > API", it sounds like it confirms what I'm saying. > In other words, if compiler, javadoc, surefire can't use the proposed API - > which is current status - it sounds fishy and we should step back and > rethink it IMHO. > > 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. 19 déc. 2023 à 16:40, Martin Desruisseaux < > martin.desruisse...@geomatys.com> a écrit : > > > Le 2023-12-19 à 15 h 30, Romain Manni-Bucau a écrit : > > > > > Side note: the api is similar for the plugins you mentionned but it is > > > not the same since you can want to compile with everything on the > > > classpath, (…snip…) > > > > > Some developers may want to put everything on the class-path at > > compile-time, other may want to use module-path. This is why the > > "modular-jar" / "classpath-jar" type proposal aims to give control to > > developers. On my side, I use module-path. > > > > > > > (…snip…) so any plugin is really isolated from others (…snip…) > > > > > I don't think it is the case. We want to let developers control their > > class-path / module-path configuration. But no matter what the > > developers choose, I think that all plugins (at least the ones for > > standard JDK tools) should apply the same configuration by default. > > Otherwise, surprising behaviour will occur. For example, if the > > developer puts everything on the classpath at compile time, but uses > > module-path at runtime, then the compiler may not report that some codes > > are trying to access non-exported packages (because this encapsulation > > is enforced only in modular projects), while the JVM may throw runtime > > exceptions or linkage errors if that encapsulation become enforced at > > runtime. > > > > So I argue that we really want the same "class-path versus module-path" > > dispatching for all plugins by default, at least as a starting point. > > Plugins may ignore some paths (e.g. doclet-path makes no sense for > > javac), or add their owns, or amend some paths, but it can be > > modifications on top of the common base. So my proposal is: > > > > * Allow developers to specify "modular-jar" / "classpath-jar" > > packaging for each dependency if they want (it would be optional). > > * Honour developer's wish consistently, in the same way, for all > > plugins expecting those kinds of paths. This is why I think a > > dedicated API for this task is desirable. > > * Plugins can ignore that common API and derive the paths themselves > > from the dependencies if they wish. > > > > > > > which enforces, as we mentionned in the original thread, each plugin > > > to have a set of dependency set identifiers to work (type in this PoC > > > but hopefully we can find something else more user friendly later). So > > > for me the common api is depService.findDependencies(dependencySetIds) > > > but nothing more. Defaults can overlap then to make it backward > > > compatible and smooth by default but don't think we should look for > > > anything else which will likely block users more than helping (as > > > current "guess" algorithm which enforces explicit configuration for it > > > to work). > > > > > The proposal would not be a guess algorithm, except for the "jar" type > > if we keep something like Maven 3 auto-detection algorithm. We have two > > kinds of things specified by the users: > > > > * The artifact type ("modular-jar", etc.). > > * The scope (runtime, compile, etc.) > > > > Determining paths require combining those two information. The process > > is deterministic for "modular-jar" and "classpath-jar" types. But in any > > case, it would not block users. Plugins would not be forced to use the > > proposed API. They could ignore it and handle dependencies themselves if > > they want. > > > > Martin > > > > >
