Ok, so i've done some more digging and it appears to be a classloader
problem in M2 rather than anything xmlbeans-specific.
The reason that some of the xmlbeans type information is not available
is that a call to
contextClassLoader.getResourceAsStream("some-generated-xmlbeans-resource")
is returning null when it should be returning non-null.
However, the class loader of the CustomMojo.class itself does return a
non-null stream as desired.
So, I have worked around this by doing the following in CustomMojo:
public void execute() throws MojoExecutionException
{
ClassLoader ccl = Thread.currentThread().getContextClassLoader();
try
{
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
... other Mojo code that calls XmlBeans here ...
}
finally
{
Thread.currentThread().setContextClassLoader(ccl);
}
}
Is this something that could be managed by the M2 runtime instead?
Kind Regards,
John Fallows.
On 9/16/05, John Fallows <[EMAIL PROTECTED]> wrote:
> Folks,
>
> I am currently developing a custom maven2 plugin that needs to parse
> some xml files (using xmlbeans). Therefore I used the m2 xmlbeans
> plugin at mojo.codehaus.org to generate the Java code for 3 different
> schema namespaces.
>
> Unit tests within the plugin verify that this code has been generated
> correctly and works as expected.
>
> However, when another m2 project attempts to use the custom plugin,
> not all the parsed xml data structures are strongly typed Java
> Objects. Instead, some are just simple XmlObjects, as though no type
> information was generated.
>
> It seems as though some of the type information cannot be located by
> the xmlbeans runtime when executed through a maven2 plugin. Could the
> classworlds classloader be somehow preventing xmlbeans from seeing all
> the type information?
>
> Kind Regards,
> John Fallows.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
