[
https://issues.apache.org/jira/browse/MCOMPILER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MCOMPILER-264:
-------------------------------------
Description:
The MCOMPILER-203 issue went part of the way to solve this problem, however it
does not help in the case where annotation processors have conflicting
dependencies. Given that this is very easy to solve on the Java end, and seems
possible to solve on the Maven end, I would very much like to see this come to
pass.
Here's some relevant info from that issue:
{quote}
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own <dependencies> and <exclusions> and so on.
{quote}
{quote}
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be
instantiated from an isolated class loader according to any rules or strategy
that you like. To specify isolated options, you can simply wrap each Processor
with one that provides the specific arguments that were configured to the
delegate processor on init().
{quote}
{quote}
Without isolation this is just one step removed from having your processors on
the class path. The difference is that processors are generally more likely to
have dependencies that conflict with other processors than to have dependencies
that conflict with the class path.
{quote}
I imagine it should even be possible to hook into an external javac task by
providing it with a proxy JAR from which annotation processor proxies (which
instantiate isolated class loaders and return proxied processors from them).
But I'd also be OK with just having this feature be unsupported for forked
javac.
was:
The MCOMPILER-203 issue went part of the way to solve this problem, however it
does not help in the case where annotation processors have conflicting
dependencies. Given that this is very easy to solve on the Java end, and seems
possible to solve on the Maven end, I would very much like to see this come to
pass.
Here's some relevant info from that issue:
{blockquote}
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own <dependencies> and <exclusions> and so on.
{blockquote}
{blockquote}
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be
instantiated from an isolated class loader according to any rules or strategy
that you like. To specify isolated options, you can simply wrap each Processor
with one that provides the specific arguments that were configured to the
delegate processor on init().
{blockquote}
{blockquote}
Without isolation this is just one step removed from having your processors on
the class path. The difference is that processors are generally more likely to
have dependencies that conflict with other processors than to have dependencies
that conflict with the class path.
{blockquote}
I imagine it should even be possible to hook into an external javac task by
providing it with a proxy JAR from which annotation processor proxies (which
instantiate isolated class loaders and return proxied processors from them).
But I'd also be OK with just having this feature be unsupported for forked
javac.
> Allow isolation of annotation processors from one another
> ---------------------------------------------------------
>
> Key: MCOMPILER-264
> URL: https://issues.apache.org/jira/browse/MCOMPILER-264
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Reporter: David M. Lloyd
>
> The MCOMPILER-203 issue went part of the way to solve this problem, however
> it does not help in the case where annotation processors have conflicting
> dependencies. Given that this is very easy to solve on the Java end, and
> seems possible to solve on the Maven end, I would very much like to see this
> come to pass.
> Here's some relevant info from that issue:
> {quote}
> An important note here would be that the processors should have their own
> dependency resolution and class loading scope, so that the versions of
> dependencies of the annotation processor do not have an impact on the
> versions used to compile the project itself (or other annotation processors).
> They should have their own <dependencies> and <exclusions> and so on.
> {quote}
> {quote}
> All you have to do with the API is call
> javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can
> be instantiated from an isolated class loader according to any rules or
> strategy that you like. To specify isolated options, you can simply wrap each
> Processor with one that provides the specific arguments that were configured
> to the delegate processor on init().
> {quote}
> {quote}
> Without isolation this is just one step removed from having your processors
> on the class path. The difference is that processors are generally more
> likely to have dependencies that conflict with other processors than to have
> dependencies that conflict with the class path.
> {quote}
> I imagine it should even be possible to hook into an external javac task by
> providing it with a proxy JAR from which annotation processor proxies (which
> instantiate isolated class loaders and return proxied processors from them).
> But I'd also be OK with just having this feature be unsupported for forked
> javac.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
