On 9/17/05, Jesse McConnell <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [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] > > > > > > > > -- > jesse mcconnell --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
