Just to be clear, the generated resources are actually packaged in my
plugin JAR.
However, when the plugin executes, it does not have access to those
resources because the context class loader on the thread is not the
class loader of the plugin.
I am proposing that the classloader of the plugin class be made the
active context class loader during plugin execution, and then restored
afterwards. (or something equivalent to these semantics)
In the XmlBeans usecase, the context class loader was still set to
something else, presumably the classloader used for main project
processing. So, that classloader could not access the contents of my
plugin's JAR and XmlBeans therefore failed to load it's necessary
resources when running inside the plugin.
This seems like a not-so-straightforward bug, but a bug nonetheless.
Kind Regards,
John Fallows.
On 9/16/05, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> 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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
