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 <[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 <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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell
