Le jeu. 2 nov. 2023 à 12:37, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit : > > > you are right they are orthogonal in terms of design but as soon as > > you get the set notion you don't need the others and I prefer to not > > multiply the way to do which is always confusing. > > > It is not necessarily a multiplication of ways of doing. Many users > would not need Set at all. For advanced users who need Set, if we > discourage the use of Set as a way to separate class-path from > module-path, it would make easier to use Set for other purposes. For > example, if a user needs different dependency sets for different > profiles, he can focus only on his core business (the profiles). If Set > was used for separating class-path from module-path, the user would need > to care about both his core business and this separation in same time, > probably using Set composition, leading to more complex and difficult to > maintain graph of sets. > Not really, set still have defaults but enable a smooth customization whereas the artifact usage does require something else anyway. My fear is that not starting by using sets you will keep working around all issues and make user life as hard as today. > > Furthermore, the set proposal does not work for the case where the > class-path versus module-path choice could be made automatically, not > based on the existing heuristic rules but instead based on user's choice > of a default policy (what to do when a dependency has no <type> > element). It could also be explicit instruction from the dependency > producer (e.g. via <packaging> element). The class-path / module-path > dispatching would become a detail that most users can ignore, but with > the possibility to control it when needed. The Set proposal is > incompatible with this convenience. It *forces* users to care about > class-path / module-path separation, even when we could free users from > this concern. > As mentionned, it just works as smooth as type usage due to the set convention we'll get. You would also note that using "type" *forces* users to care about this separation too in an unexpected way. > > Keeping Set and JPMS as orthogonal issues would both keep automation > possible (with rules under user's control), and make easier to use Set > for core business logic by reducing the complexity of Set graphs. > I don't grok this one, set has no more complexity than having dependencies and most builds require this customization (it is worse using jpms from my experience, the "smooth" builds are only PoC or demos). > > > > Since the dependency option does not work generally speaking, I'm > > clearly on the other side > > > I still do not understand what is the issue with dependency. Transitive > dependencies would be managed in the same way as today. It may require a > modification of the POM model for additional metadata, but this is > indeed what we are proposing. Even the need for POM modification is > unsure if the existing <type> element is used. > Same way as today: I import helidon (which is fully jpms friendly) so I get helidon-server on the module-path but helidon-common on the classpath? (indeed keep in mind if you fix this you will get the opposite case blowing up). Also keep in mind the pom modification is *not* an option as commented and would mean the consumer depends on the consumed artifact which, we saw it, is not the case at all with java modules (90% will want modules on classpath but the source build would use type=module). So at the end we are exactly in the current (doing no change at all) situation where you need to tune all your stack to be stable, reliable and properly handled. > > > > *if we think JPMS needs any more advanced support than today* which is > > still something I'm not sure. > > > The current support is a blocker for non-simple projects. Not improving > that support would be equivalent to deciding for users, at their place, > that they do not need JPMS. > Yes and no but ultimately it is by JPMS design IMHO, not due to the build tool so I still think maven can say we don't do anything more than helping to link gav to physical location more closely. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
