Le dim. 29 oct. 2023 à 21:11, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit : > > > > *type* is not a good solution for jpms, only dependency can help > > > Since we are talking about specifying the type of dependencies, I do not > understand well what would not work exactly? > Previous examples show that: 1. type depends the context (=plugin, even in a single module) 2. lack of transitiveness support (keep in mind module will be lost most of the time as of today and there is no guarantee if we dont loose it that maven will support it later, ie it is lost for consumers) > > One thing that we may need is a way for a dependency to said "unless the > user specifies otherwise in the <type> element, put me by default on the > module-path". Is it related to the objection? > This is ok but actually iso with what we have today "put it on classpath until requested otherwise". > > > > But once again, how much project would we cover, in years EE and > > Spring didnt embrace jpms and even if some minor integration can be > > hoped it will not become mainsteam anytime soon (...snip...) > > > Not all applications depend on Spring or EE. For non-Spring > applications, as said previously in this thread, this is a > chicken-and-egg issue. There are companies that would love to use JPMS > (e.g. for reducing the "classpath hell" issue) but are blocked by > limitations of tools. Another argument is that JPMS improves security by > providing stronger encapsulation (only exported packages can be used, > and reflection is constrained). Security is a hot topic for governments > in those time, maybe we should not neglect features that can help us. > No-one is forced to use JPMS, but for those who want, it should not be > as hard as it is today. My expectation is that once JPMS become well > supported by tools like Maven, we will see a great increase in its usage. > I understand and I saw the chicken egg point but I don't think it is. As a matter of fact it does work today and very few people are embracing jpms (more than naming for downstream consumers), using ir or even willing to use it. Maven is all about conventions so mainstream and mainstream is not and will probably never be JPMS (keep in mind it was designed for the jdk very few for end users, which also explains why very few major frameworks integrated it). So yes, we want to support it and the good news is we do. It is more than fine to do an extension on github which helps but the type solution does not work well from what I tested some years ago as soon as you have more than one project or build project modules separately (not using the root reactor). > > Martin > >
