maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <>
Subject AW: Maven 4.0.0
Date Sun, 05 Nov 2017 21:27:41 GMT

Adding annotations and processor as a compiletime dependency sounds like a reasonable thing.
It would however be cool if the JAR could describe which package needs to go on the classpath
and which is processor impl. (and having a different artifact for runtime)


Von: Mark Derricutt
Gesendet: Sonntag, 5. November 2017 22:20
An: Maven Developers List
Betreff: Re: Maven 4.0.0

On 5 Nov 2017, at 10:42, Robert Scholte wrote:
I would like to drop strict scopes in general and give plugins the opportunity to depend on
specific scoped dependencies.
How would this help with annotations tho? The main issue I'm facing is having a standard m-c-p
plugin definition in a parent ( or tile ) but needing different annotation processors used
per project. With the current plugin, this means either listing them as standard dependencies
and have them auto-scanned, and pollute the compilation classpath, or list every possible
annotation processor dependency we may use in our projects in the parent, which is less than
I hope you are aware that modules already end up on the modulepath based on the moduledescriptor(s).
So I don't see the need for this scope. (unless you have this wish that in the end Maven will
create the module descriptor based on this, but I still think we shouldn't do that)
I remembered reading something about this, and assumed it was the case if there was a module-info.class,
but what if its a standard jar with an Automatic-Module-Name header? Does that fall into the
module path or classpath? Having control for this case may be useful.
I recognize this wish. The best solution is to make the dependency optional.
The problem with this is that the dependency is still on the classpath for say surefire, which
can influence behaviour.

"The ease with which a change can be implemented has no relevance at all to whether it is
the right change for the (Java) Platform for all time." — Mark Reinhold.
Mark Derricutt

View raw message