[jira] [Updated] (MCOMPILER-264) Allow isolation of annotation processors from one another

["David M. Lloyd (JIRA)" <ji...@apache.org>]

     [ 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)