this is becoming a fairly common problem domain it seems
as far as I know there is still no real straight-forward way to solve this
outside of mucking around with classloaders in your plugin.
there is the <extentions> mechanism which would probably work as well but
that is pretty cumbersome for this particular purpose...
The rule of thumb is that the plugin runs in its own classloader and has
access to the declared dependencies of the _plugin_ not the dependencies of
the project that the plugin in running within...if you need to process the
dependencies of the project in some way in your plugin then you need to do
it by hand.
there are a couple of examples of this in the mojo project, the
maven-execute-plugin in the sandbox does this in a pretty simple sort of way
if you want to take a look at that. (make sure you have
@requiresDependencyResolution in the class lvl javadocs as well)
List files = project.getCompileClasspathElements();
URL[] urls = new URL[files.size()];
for (int i = 0; i < files.size(); ++i) {
getLog().debug((String)files.get(i));
urls[i] = new File((String)files.get(i)).toURL();
}
URLClassLoader loader = new URLClassLoader(urls, Thread.currentThread()
.getContextClassLoader());
Class types[] = {String[].class};
String[] args = (String[])params.toArray(new String[params.size()]);
Class c = loader.loadClass(classname);
Method m = c.getMethod("main", types);
m.invoke(m, new Object[]{args});
I have brought up the subject a number of times in different ways on irc but
no real _good_ solution has been decided on. it isn't that bad to just do it
yourself though...so don't worry, your not missing out on some spiffy way to
do it...that I know about at least :)
Jesse
On 9/16/05, John Fallows <[EMAIL PROTECTED]> wrote:
>
> 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 <http://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]
>
>
--
jesse mcconnell
