[
http://jira.codehaus.org/browse/MOJO-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204716#action_204716
]
Benjamin Bentmann commented on MOJO-1458:
-----------------------------------------
I don't have access to JRockit but the code works also for IBM's JDKs. At least
the main class loaded by the plugin must be in the {{com.sun.*}} packages and
if JRockit really delegates the class loading related work to classes in other
packages, well, have somebody fill an issue and we tune plugin. Nothing is
perfect, but hacking the system (or any other) class loader like before is a
no-no.
> Fix non-forked APT invocation to not hack system class loader
> -------------------------------------------------------------
>
> Key: MOJO-1458
> URL: http://jira.codehaus.org/browse/MOJO-1458
> Project: Mojo
> Issue Type: Bug
> Components: apt
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
>
> Hacking the system class loader like currently in {{AptUtils}} is bad:
> {code:java}
> Method method = URLClassLoader.class.getDeclaredMethod( "addURL", new Class[]
> { URL.class } );
> method.setAccessible( true );
> method.invoke( ClassLoader.getSystemClassLoader(), new Object[] {
> toolsJar.toURL() } );
> {code}
> In particular, this won't work with the [class loader boundaries in Maven
> 3.x|http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading].
> See also [TOBAGO-256|https://issues.apache.org/jira/browse/TOBAGO-256] for a
> related issue.
> Instead of hacking other people's class loaders, the plugin should create its
> own class loader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
