Le mar. 19 déc. 2023 à 18:12, Tamás Cservenák <ta...@cservenak.net> a écrit :
> 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? > The example I explained before: * compilation: either make things simple or just enable to compile part of the code which does not use modules (does not prevent to compile with module meta) * doc: you want to document module part so you have to compile it as a module * surefire: you likely want to test both cases This is just a simple not uncommon case you hit when building a lib with JPMS one (agree it is more rare when you use JPMS just for a single app). What I don't want if we create all these new things to not enable to use paths but just for a particular nice case and ultimately make things more complicated and be back to the current status where you just make the command explicit. > > > > 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 > > > > > > > > >
