[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090143#comment-15090143
]
Andreas Gudian commented on MCOMPILER-203:
------------------------------------------
Ah, ok, right. I guess that could work for the javax.tools case.
Regarding the external javac, the use case is for whenever you need to compile
/ test your code with a different compiler than the JDK used to execute Maven -
e.g. for building code for a JDK version older than the runtime-requirements of
the maven version or of some plugins, a JDK of a different vendor, or for
running integration tests of annotation-processors against multiple different
JDKs within one build... ;)
So it's still an important capability to have and to keep.
Anyway, I think we're getting a little off-topic and that separation idea
should be discussed in MCOMPILER-207 after all - I don't see it within the
scope of this issue.
> Allow compiler-plugin to specify annotation processor dependencies
> ------------------------------------------------------------------
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
> Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
> Reporter: David M. Lloyd
> Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
