Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 13 Jun 2013 22:17:03 -0500 (CDT)
From: "David M. Lloyd (JIRA)" <jira@codehaus.org>
To: issues@maven.apache.org
Message-ID: 
 <JIRA.146751.1371179786920.3789.1371179823225@codehaus01.managed.contegix.com>
In-Reply-To: <JIRA.146751.1371179786920@codehaus01.managed.contegix.com>
References: <JIRA.146751.1371179786920@codehaus01.managed.contegix.com>
Subject: [jira] (MCOMPILER-207) Support separate GAV list for annotation
 processors
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David M. Lloyd created MCOMPILER-207:
----------------------------------------

             Summary: Support separate GAV list for annotation processors
                 Key: MCOMPILER-207
                 URL: https://jira.codehaus.org/browse/MCOMPILER-207
             Project: Maven 2.x Compiler Plugin
          Issue Type: New Feature
            Reporter: David M. Lloyd


Currently, the compiler plugin searches for annotation processors on the compile class path using the default search algorithm.  This can be problematic when having annotation processor JARs or their dependencies on the compile classpath adversely affects compilation behavior, sometimes even making compilation impossible.

It should be possible to alternatively explicitly give a list of artifacts to pass in to the compiler as the annotation processor path.  This would correspond to the standard "-processorpath" option.  When given in this way, these artifacts (and their transitive dependencies) would have an isolated class loader which could "see" classes on the compile class path but not *be* "seen" by classes on the compile class path.

This list would be defined in the compiler plugin configuration section as a list of artifacts with optional nested exclusions and that sort of thing (no scope though, as annotation processing is only applicable to compilation).  I imagine that these artifacts would behave largely similarly to normal dependencies (i.e. subject to {{<dependencyManagement>}} sections), and any dependencies which are already on the compile class path would be chosen from the compile class loader rather than being duplicated in the processor class loader.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira