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 ideal. > 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. Mark --- "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 http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt
signature.asc
Description: OpenPGP digital signature
