On Jul 11, 2006, at 11:41 AM, Jason Dillon wrote:

Thanks for following up on this.

Would have been nice if there were comments in the codebase to this effect.

true.

Was there any reason why the setters were all invoked through reflection as well?

well, in the m1 plugin the class of the PackageBuilder instance is in a different classloader than the PackageBuilderShell, so I don't see how there is any other way to call the setters. Am I missing something? If we said PackageBuilder pb = (PackageBuilder) packageBuilderInstance we'd get a class cast exception.

I think what you've done for m2 should work: if we start getting bizarre class cast exceptions when trying to build configs we'll have to revisit this question.

Note that the m2 plugin had already switched to using the same classloader for PBSM and PB, so the reflective setter calls were pointless.

thanks
david jencks


--jason


On Jul 11, 2006, at 8:43 AM, David Jencks wrote:

Jason Dillon asked last night on IRC why the PackgeBuilderShellMojo for the m2 packaging plugin used reflection to create the PackageBuilder. We need to control the classloader for PackageBuilder pretty closely so it has the same classpath as j2ee-system. In maven 1, IIUC, plugins get instantiated using a child classloader of the project calling the plugin: this classloader typically has a more or less random selection of large numbers of geronimo jars in it, far more than j2ee-system, and in particular including all the classes for the dependencies of the module/configuration you are trying to build. The only solution I could see for m1 was to construct a classloader myself and load PackageBuilder in my own classloader and access the instance by reflection.

I believe the situation is better in m2 and that the plugin is instantiated using a classloader determined solely by the plugin's pom. If so, we should be safe in eliminating this extra reflection code and in fact using PackageBuilder directly without the "shell". If not, we should keep using the inconvenient reflection code.

thanks
david jencks



Reply via email to