Le jeu. 2 nov. 2023 à 19:49, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit : > > > Now, do the same example but with app in a classpath centric build > > (spring boot, EE, ...) which consumes lib1 as a classpath jar even if > > it is a module in its original pom (perfectly valid). > > > Consuming lib1 on the classpath is *not* perfectly valid. It depends on > the library. For being valid, the library must have applied some > workarounds such as duplicating module-info into META-INF/services. If > the library hasn't applied those workarounds, consuming the library on > the classpath will break it. > The workaround doing duplication in META-INF is not too difficult (but > not always easy neither). However, some other workarounds are more > difficult. For example, loading new JAR files at runtime is done in a > very different way (ClassLoader versus ModuleLayer). A library producer > may choose to not support execution on the classpath anymore, e.g. in > order to avoid maintaining two different JAR loading systems. They may > lost some users, but it is not up to us to decide for them. > Agree but as of today libs can't ignore classpath cause it stays the majority of consumers so it is "as if" in this thread IMHO. > > Regarding Spring Boot, the idea that a non-JPMS application must have > everything on the classpath is a common misconception. A non-JPMS > application can still have dependencies on the module-path. Some peoples > seem to be doing exactly that with Spring Boot [1]. I also demonstrated > that 4 months ago with a Maven and Gradle project [2] for explaining the > issue with current heuristic rules. > > [1] > https://stackoverflow.com/questions/74214182/how-to-get-spring-boot-project-work-with-jpms > [2]https://github.com/Geomatys/MavenModulepathBug Also agree but if you take the most common packaging which is the fatjar (agree it is wrong for JPMS unrelated reason but still) it does not support a single module. Same for war packaging and saw almost nobody using the plain classpath packaging in real life (which would be the most valid one). So agree about the language shortcut but here again it is the world we are in today and probably tomorrow. Side note: I'm far to speak about what we can do, we can implementing lib versioning on top of module layers but "nobody" does/uses it seriously today for ex. So it is really about maven spirit which is about "works for most" and refining this "most" and AFAIK it is not JPMS. > > > > > You can make one of both cases working but not both with your > > proposal. Indeed last one will be broken even if it is the most common > > one (so we break maven philosophy - and user interaction IMHO). > > > I still do not see where is the conflict. Both scenarios should work, > including the last one even if the dependency is put on the module-path > of a classpath-centric environment. Actually I think that keeping JPMS > dependencies on the module-path is what should be done. If a user is > nevertheless facing issues, giving him control is the whole point of the > proposal. > Wait, this is what we have today then so we are good. But yes, one of both scenario is broken if you test it cause you inherit a context whereas you can be consummed in two contexts so one is always wrong until you redo the work...exactly as today so no gain there. > > > > By design there is no way to make it work smoothly at artifact level. > > > Is this statement based on the idea that a classpath-centric application > would need to move module-path dependencies to the class-path? If yes, I > tried to explain above that this is a misconception (executable proof of > concept provided). If no, can you explain where is the problem, keeping > in mind that a dependency on the module-path is not necessarily a > problem even for a classpath-centric application? > Similarly your statement is right, "a dep on the module-path can be a problem" is true as well so my opinion is we should respect the user runtime (if not using jpms then don't set module-path). > > > > Until JPMS reach 40% of projects I guess we should be able to leave > > with it and it avoids to introduce any new concept or mess up what > > type is for end users > > > This is not a fair criterion if Maven is making JPMS adoption so hard > (chicken-and-egg problem). Also, this thread initially started as an > issue about agents. JPMS has been added to this discussion because the > issue is basically the same: controlling the path. Tamas's proposal is > trying to address not only JPMS, but also agent, doclet, taglet, > annotation processor and possibly yet more tools to appear in the > future, at all once with one uniform mechanism. > Maven does not, JPMS setup is documented since java 9 and we got no real complains AFAIK (agree it comes from time to time but it is quite rare in practise compared to the user base IMHO). Agree about having an uniform solution and this is why I mention that using type is just about trying to fit the set notion in the current model but without embracing the design which makes it solving the issue (assinging a set per "path" need). So we would get something new with the same issues than today, I'm not a big fan of this idea even if it can enable to move a step forward, we still wouldn't be able to enter the house somehow. > > Martin > >
