Le 2023-10-23 à 11 h 28, Romain Manni-Bucau a écrit :
anyway, if we go with the "usages" path we can want to enable a
<dependenciesSet> definition containing <dependencies> wrapped in a
scope (<dependencySet><module><dependency>....</></></>) this way you
can reference a dependency set in a plugin or even main dependencies
(import all).
Maybe, but the <usages> element has the advantage of allowing the same
dependency to be put in different kinds of path (doclet, annotation
processor, etc.) while the <dependencySet> approach would require to
repeat the dependencies.
That said, as mentionned, it does *not* solve the issue for agents due
to the inheritance nature where order will be lost until we add an
order attribute/element.
The <usages> element alone may not be sufficient for covering all agent
needs, in the same way as it is not sufficient for covering all JPMS
needs. We will have more complexity to handle anyway: ordering for
agents, add-exports/add-opens for JPMS. But the <usages> element offer a
common place where to handle a common problem.
Regarding ordering, this is important for classpath as well. Can't it be
just the ordering of <dependency> elements in the POM?
Martin
