Le mer. 3 janv. 2024 à 14:45, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit : > >> I would like to see a proof in the form of an "hello world" > >> application (…snip…) > > > > Yot got some on github. > > > Can you share the URL? > > > >> defaulting on the classpath is fine only if the library developers > >> applied workarounds (…snip…) > >> > > The opposite got proven too > > > Which opposite do you mean? If it is "defaulting on the module-path", > this is not the proposal. The proposal is: comply to developers > instructions when they are explicit, otherwise check if the dependency > is modularized. > No this part is fine, think I misunderstood the phrasing (thought it was about an uninified enforced path) but if it is what you meant no issue there, sorry about that. > > > > I fail to see why you try to impose a single reduced use case to core. > > > Because currently, class-path is managed in core. If class-path become > managed in a different place, I will move module-path management in that > place too. No matter where class-path is managed, I think that > module-path and patch-modules need to be managed in the same place, > because module-path is (partially or fully) a replacement for > class-path. And I think that this management needs to be the same for > all standard Java tools, at least by default. > I can agree with that so let's move it in a plugin related code maybe? > > > > Workarounds are needed both ways but a lib can't, today and likely for > > some serious years, enforce people to consume it as a module, just > > because most of the runtime environments don't support it well enough > > (service loader is a good one here). > > > Workarounds are needed only if a library needs to be usable on *both* > class-path and module-path. Whether a library developer targets only the > class-path, or only the module-path, or both, is developer's choice. On > Maven side, I believe that our task is only to make all those 3 options > as easy as each other. Nothing more. > True but it is a bit more cause maven is opiniated and I guess this is where we wouldnt converge so hopefully we would find a solution which comply to all 3 smoothly (otherwise current state is already good so hope we don't get at the opposite ;)). My side note is that, from maven standpoint, we should probably consider the default choice is both for 5-6 years (we can revise it later indeed). > > I'm not sure to understand correctly the allusion to service loader, > because the sentence seems to said that java.util.ServiceLoader does not > support modules well, which is not true. Or maybe you identified issues > when a service has some implementations on the class-path and some other > implementations on the module-path? Even if it is the case, the proposal > allows developers to force a dependency to be on the class-path. It is > just that if a dependency is forced on the class-path, then *by default* > it will be there for all tools: java, javac, javadoc, etc. But even that > is overrideable. > The SPI registration is different depending you are on the class or module path. And as a lib you often need to support both (sadly, never said I was happy about that java choice but that's real life). I would still be happy to get an overridable example, maybe more on native lib case which needs the type=extension thing (since jar is the default loosing the extension configuration provided by type is fine) so how do I resolve a "library-path" lib which is org/foo/bar/1.0.0/bar-1.0.0.so for example? > > > > Just give it a try to write a small lib (a "commons" for ex ;)) and > > make it classpath and module friendly using a module aware javadoc and > > mainly a classpath build. Now do a lib consuming this first lib with > > the same constraint (be consumable by anyone since most of libs desire > > that) and you'll see what I mean. > > > I don't see what you mean. I proved my point with a test case which does > what you said: a small lib (called "service") and a lib consuming it > (called "client"). Can you show your point by modifying this test case, > or create a new one please? > > https://github.com/Geomatys/MavenModulepathBug No need to modify it, just run javadoc:aggregate on this example, this should use only module mode whereas build can use classpath (this is the expectation in my example) so javadoc and javac don't share the module/class paths. > > > > > once again it is used today by being explicit, requires a bit more > > work but you can't proove it is not doable > > > I proved my point with above test case. Please prove me wrong by fixing > above test case without transforming Maven into Ant (i.e. without > declaring module-path in <compilerArgs> or similar option). > > > > Rewind a bit the threads and see that the original topics in that area > > were not JPMS - some started before JPMS - but processors, agents to > > cite the most known. You still don't solve that since both of them are > > obvious path which are not consistent between plugins. > > > I answered those points in previous emails. The discussion is going in > circles. Lets stop arguing and talk with codes and test cases. > > > > (about --add-opens option) This will work when you control the JVM > > options but most libs will desire to avoid that and classpath is one > > of the known solutions which works well. > > > As they wish. The proposal is not blocking the use of class-path. > > > >> Why would the exec plugin wants to ignore the module-path by design? > >> > > Cause it does not launch a JVM so several options will not be not > > available. > > > See addOpens(…), addReads(…) and addExports(…) in > java.lang.ModuleLayer.Controller. I already use ModuleLayer in my own > code for loading user-specified JAR files (while I admit I didn't tried > addOpens(…) and consort). > This is part of the issue but as explained it will only partially work and several cases can be broken (mainly the ones related to the JVM itself due to the exec:java lifecycle) so this is not a technically completly valid solution (sadly - this is kind of the same issue you can get with javaagent if you know this one better). > > > > Do you have an example to define a custom "resource" type in a pom - > > no code? If so this part works for me. > > > Can you elaborate on your use case? After a "resource" type has been > created, where do you specify how to use the path (which option on which > tools) if there is no code? Is it a Maven 4 goal to allows new plugins > to be created without Java code? > You said you can declare a type from a pom without coding anything. So let's assume I have a plugin (not an extension cause I don't think we want all plugins to be extensions due to the class loading it implies) which consumes type=resource, can you show me how I would code it in my pom, this is a bit blurry cause for me it needs some registration when ext!=jar? > > > >> New paths do not need recoding Maven core. Only *choices between two > >> or more paths* need to be coded, and even that part can be made > >> plugable in a next version if desired. > >> > > Agree but means these types neither needs to be there ;). > > > See above reply. If class-path management is moved outside core, I will > move module-path management to the same place. > > Martin > >
