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
>
>

Reply via email to