Problem Solved!
It was, of course, a classloader issue. To solve the problem I created my
own URLClassLoader instance and gave it the URLs in of my MoJo's
classloader. Then it was a simple matter to load and instantiate my utility
class from there.
Because I also need access to the project's classpath I also used
${project.runtimeClasspathElements} to import that list.
The relevant solution bits are shown at: http://rafb.net/p/TmK9TL26.html
Thanks for the pointers Jerome. I would still be beating my head on the desk
without your help!
> On 4/4/07, James CE Johnson <[EMAIL PROTECTED]> wrote:
>> Hi Jerome,
>>
>> My latest nohup.out is http://rafb.net/p/seMDUu17.html. I've dumped the
>> classloader of my app as well as the system classloader. It appears that
>> I have a RealmClassloader loading my classes and it has everything it
>> needs.
>>
>> However, http://rafb.net/p/qC12GT63.html captures my execution from
>> within Eclipse. Here we see that all of the dependencies are in the
>> system classloader.
>>
>> Perhaps Spring is looking to the (mostly empty) system classloader in
>> the case where it fails?
>>
>> Any insights would be appreciated.
>
> In the xfire maven plugin, i've had to override the class loader,
> otherwise Spring would not find the appropriate classes/resources. See
>
> http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/xfire-maven-plugin/src/main/java/org/codehaus/mojo/xfire/WsdlgenMojo.java
>
> I would guess that you need to do something similar in your plugin.
>
> Cheers,
>
> J
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
