> Exactly the opposite right?
of what?
> If we do that then a particular plugin can use that but all others
> will don't read it right
Whats "right" depends on the context, at least one don't need a new
discussion/extension for each use case, also most of these discussions
cover the needs of the maven-* plugins but often forget custom plugins
that have other demands apart from "everyone can use this for everything".
> until you rewrite the full maven plugin ecosystem
Usually such things don't touch really *everything" and especially this
will not require a rewrite for anything but the same as a new <whatever>
element would need beside that <whatever> will always only cover one
specific use-case, while allowing generic extensibility would allow to
cover a wide range of use-cases.
Am 23.10.23 um 11:34 schrieb Romain Manni-Bucau:
Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich <m...@laeubi-soft.de> a
écrit :
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>
Exactly the opposite right?
If we do that then a particular plugin can use that but all others will
don't read it right so ultimately you reach the exact opposite of what you
aim for until you rewrite the full maven plugin ecosystem which is
obviously not the goal IMHO.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
