I always wished there was support for generic <properties> element in
<dependency> this can then be literally used for everything in an
extensible way.
<dependencies>
<dependency>
... usual stuff ...
<properties>
<usages>module</usages>
<whatever>...</whatever>
<properties>
</dependency>
</dependencies>
Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:
Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit :
that said, on my side, not sure JPMS will be widely adopted anytime
soon so can be a false problem.
I think that this is a chicken-and-egg problem: some peoples renounce to
JPMS because tools support is poor (at least in Maven and Gradle), and
tools don't improve their support because they think that JPMS is not
widely-used. We sometime see in mailing lists or blogs blames saying
that JPMS is half-backed, while actually the problem lies in the tools.
Regarding the original proposal, I would suggest an amendment for
addressing more problems at once: not only agent, but also doclet,
annotation processor and one aspect of JPMS. Instead of an <agent> block
in <dependencies>, I suggest a new <usages> element inside <dependency>
saying where to put that dependency. Example:
<dependencies>
<dependency>
... usual stuff ...
<usages>module</usages>
</dependency>
</dependencies>
Where <usages> can contain a comma-separated list of the following:
class, module, processor-class, processor-module, doclet, agent
where
* class and module are mutually exclusive,
* processor-class and processor-module are mutually exclusive.
This is not exactly the same as the existing <type> element because
<type> changes the artifact to use (main versus test) without changing
where to put it (class-path versus module-path), while the proposed
<usages> is the converse.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
