You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by John Fallows <jo...@gmail.com> on 2005/09/16 10:25:38 UTC
[m2] xmlbeans generated code in an m2 plugin
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] xmlbeans generated code in an m2 plugin
Posted by John Fallows <jo...@gmail.com>.
On 9/17/05, Jesse McConnell <je...@gmail.com> wrote:
> I see what is going on...
>
> atm, I would say that you are probably doing what is needed given the way
> you have things packaged..
>
> it might help to pull out those generated classes from your plugin into
> thier own dependency, which could be simply a subproject in your project
> tree that is referenced as a dependency...I would think that would work, but
> having not tried it...I dunno for sure.
>
> If you think it is a bug then I would raise a jira issue on it, either as a
> comment on http://jira.codehaus.org/browse/MNG-697 or as a
> seperate issue entirey and maybe mention/link to that issue since it is a
> stab at addressing this kind of problem space (classpaths in plugins)
This problem seems unrelated to MNG-697 since it does not require the
plugin to access classes from the main project.
Filed JIRA Issue
MNG-908 Context class loader references incorrect realm during
plugin execution
http://jira.codehaus.org/browse/MNG-908
Kind Regards,
John Fallows.
> On 9/16/05, John Fallows <jo...@gmail.com> wrote:
> >
> > 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 < jesse.mailing.lists@gmail.com> 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 <john.r.fallows@gmail.com > 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 < john.r.fallows@gmail.com> 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:
> > > users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > jesse mcconnell
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> --
> jesse mcconnell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] xmlbeans generated code in an m2 plugin
Posted by Jesse McConnell <je...@gmail.com>.
I see what is going on...
atm, I would say that you are probably doing what is needed given the way
you have things packaged..
it might help to pull out those generated classes from your plugin into
thier own dependency, which could be simply a subproject in your project
tree that is referenced as a dependency...I would think that would work, but
having not tried it...I dunno for sure.
If you think it is a bug then I would raise a jira issue on it, either as a
comment on http://jira.codehaus.org/browse/MNG-697 or as a seperate issue
entirey and maybe mention/link to that issue since it is a stab at
addressing this kind of problem space (classpaths in plugins)
On 9/16/05, John Fallows <jo...@gmail.com> wrote:
>
> 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 <je...@gmail.com> 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 <jo...@gmail.com> 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 < john.r.fallows@gmail.com> 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:
> > users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
> >
> > --
> > jesse mcconnell
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
jesse mcconnell
Re: [m2] xmlbeans generated code in an m2 plugin
Posted by John Fallows <jo...@gmail.com>.
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 <je...@gmail.com> 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 <jo...@gmail.com> 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 < john.r.fallows@gmail.com> 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:
> users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> --
> jesse mcconnell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] xmlbeans generated code in an m2 plugin
Posted by Jesse McConnell <je...@gmail.com>.
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 <jo...@gmail.com> 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 <jo...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
jesse mcconnell
Re: [m2] xmlbeans generated code in an m2 plugin
Posted by John Fallows <jo...@gmail.com>.
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 <jo...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org