[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089988#comment-15089988
]
Andreas Gudian commented on MCOMPILER-203:
------------------------------------------
>From the new documentation:
{quote}
Classpath elements to supply as annotation processor path. If specified, the
compiler will detect annotation processors only in those classpath elements. If
omitted, the default classpath is used to detect annotation processors. The
detection itself depends on the configuration of annotationProcessors.
Each classpath element is specified using their Maven coordinates (groupId,
artifactId, version, classifier, type). Transitive dependencies are added
automatically. Example:
{code}
<configuration>
<annotationProcessorPaths>
<path>
<groupId>org.sample</groupId>
<artifactId>sample-annotation-processor</artifactId>
<version>1.2.3</version>
</path>
<!-- ... more ... -->
</annotationProcessorPaths>
</configuration>
{code}
{quote}
Transitive dependencies are resolved. Exclusions can't be defined, and just as
with plugin-dependencies, the {{dependencyManagement}} section does NOT have
any influence on these processor classpath elements.
As to your question with the isolation: it's not possible to hand over
different sets of processor classpaths to javac - there is only one
{{-processorpath}} option there.
If you have multiple processors that have conflicting dependencies, then please
take that up with the providers of those processors. Both Javac and the Eclipse
JDT compiler implementation only support that one processor path and developers
of such processors should be aware of that. That's actually a good use case for
the maven-shade-plugin, where dependencies are mapped to private packages and
inlined into the jar (the so-called fat-jar). That's how it's done for example
in the [MapStruct
processor|https://github.com/mapstruct/mapstruct/blob/master/processor/pom.xml].
> 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)
