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.
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.
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.
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.
*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.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
