|
»
»
Do maven plugin (mojo) developers have access to a classloader based on ${project.artifacts}, or do we need to build it up ourselves?
|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
 |
Do maven plugin (mojo) developers have access to a classloader based on ${project.artifacts}, or do we need to build it up ourselves?
by buildlackey
::
Rate this Message:
Hi, I'm interested in using the spring beandoc mojo, but it has some issues, which I believe were previously touched on in this
forum. Basically, my problem is that the spring bean doc plugin is failing for me when i try to process spring beans that use imports the reference other bean files by class path. e.g.: <import resource="classpath:applicationContext-dao.xml" /> This seems to be a result of the fact that when the mojo executes it's Thread's currentContextClassLoader doesn't have references to the artifacts (jars) that are used at compile time. There seems to be a bug related to this issue that was closed as wontFix http://jira.codehaus.org/browse/MNG-697 The question which launched the original thread of discussion (which I think was sent by the original developer of the spring bean doc mojo) is here: http://www.nabble.com/-m2--plugin-classpath-question-to662848.html#a662848 The response to the question was basically >>You can get the JARs for the project's artifacts using the ${project.artifacts} expression. I found some plugin code (at the URL below) that seems to (more or less) follow this approach... http://metagenome.ncl.ac.uk/websvn/filedetails.php?repname=fluxion&path=%2Ftrunk%2Fstack%2Fgenerate-beans-plugin%2Fsrc%2Fmain%2Fjava%2Forg%2Fcomparagrid%2Ffluxion%2Fplugins%2Fbeangen%2FGenerateBeansMojo.java&rev=532&sc=1 I guess I'll fix the spring bean doc plugin using this approach, unless someone suggests a better one. The code that I'm planning to write to do mostly borrows from GenerateBeansMojo.java (in the link above).. Any comments or suggestions are most welcome>>> class MyMojo..... extends AbstractMojo { /** * The set of artifact artifacts * * @parameter expression = "${project.artifacts}" * @readonly */ private Collection artifacts; /** * Resolve Maven artifacts from "${project.artifacts}" and set up the current * context class loader to load the classes from these artifacts. * Calling class should restore original classloader... this method should probably * return the original (before the current threads' context class loader was changed) * * <p/> * NOTE that this seems to be necessary to work around a maven bug. The * plugin should have these dependencies available to it's classloader, but * the classloader seems to be persistent from previous invocations, and as * such I'm having to load the classes myself. * * @throws MojoExecutionException */ private void resolveDependencies() throws MojoExecutionException { try { List<URL> allURLs = new ArrayList<URL>(); for (Object o : artifacts) { Artifact artifact = (Artifact) o; allURLs.add(artifact.getFile().toURL()); } // TO FIX CLASSLOADER BUG // Set up the classloader to load from all declared artifacts in this project URL[] urls = new URL[allURLs.size()]; urls = allURLs.toArray(urls); URLClassLoader loader = new URLClassLoader(urls, Thread.currentThread().getContextClassLoader()); Thread.currentThread().setContextClassLoader(loader); // // TODO - this fix is definately NOT a desirable solution // // the plugin classloader will gradually accumulate more and more redundant stuff // // but it works for now, although there are duplicates being loaded and it isn't right! } catch (MalformedURLException e) { throw new MojoExecutionException( "Unable to access " + classDir.getAbsolutePath()); } } thanks -- Chris |
|
|
RE: Do maven plugin (mojo) developers have access to a classloader based on ${project.artifacts}, or do we need to build it up ourselves?
by Bernhard David
::
Rate this Message:
Hello,
I hit the same problem a while ago, what I did was List<URL> classpath = m_project.getRuntimeClasspathElements(); where m_project is of course the parameter ${project} (MavenProject). From there, it's no problem to construct an UrlClassLoader and run a new thread with it as context class loader. Yours, David Bernhard > -----Original Message----- > From: upstreamnet [mailto:upstreamnet@...] > Sent: 23 June 2008 08:39 > To: users@... > Subject: Do maven plugin (mojo) developers have access to a > classloader based on ${project.artifacts}, or do we need to > build it up ourselves? > > > Hi, I'm interested in using the spring beandoc mojo, but it > has some issues, > which I believe were previously touched on in this > forum. > > Basically, my problem is that the spring bean doc plugin is > failing for me > when i try to process > spring beans that use imports the reference other bean files > by class path. > e.g.: > > <import resource="classpath:applicationContext-dao.xml" /> > > > This seems to be a result of the fact that when the mojo executes it's > Thread's currentContextClassLoader > doesn't have references to the artifacts (jars) that are used > at compile > time. > > There seems to be a bug related to this issue that was > closed as wontFix > > http://jira.codehaus.org/browse/MNG-697 > > The question which launched the original thread of discussion > (which I think > was sent by the original developer of the spring bean doc > mojo) is here: > > > http://www.nabble.com/-m2--plugin-classpath-question-to662848. > > > The response to the question was basically > >>You can get the JARs for the project's artifacts using the > ${project.artifacts} expression. > > > I found some plugin code (at the URL below) > that seems to (more or less) follow this approach... > > http://metagenome.ncl.ac.uk/websvn/filedetails.php?repname=flu 2Fjava%2Forg%2Fcomparagrid%2Ffluxion%2Fplugins%2Fbeangen%2FGen > erateBeansMojo.java&rev=532&sc=1 > > > I guess I'll fix the spring bean doc plugin using this > approach, unless > someone suggests a better one. > > > The code that I'm planning to write to do mostly borrows from > GenerateBeansMojo.java (in the link above).. > Any comments or suggestions are most welcome>>> > > > class MyMojo..... extends AbstractMojo { > > /** > * The set of artifact artifacts > * > * @parameter expression = "${project.artifacts}" > * @readonly > */ > private Collection artifacts; > > > > /** > * Resolve Maven artifacts from "${project.artifacts}" and > set up the > current > * context class loader to load the classes from these artifacts. > > * Calling class should restore original classloader... this method > should probably > * return the original (before the current threads' > context class loader > was changed) > * > * <p/> > * NOTE that this seems to be necessary to work around a > maven bug. The > * plugin should have these dependencies available to it's > classloader, > but > * the classloader seems to be persistent from previous > invocations, and > as > * such I'm having to load the classes myself. > * > * @throws MojoExecutionException > */ > private void resolveDependencies() throws MojoExecutionException > { > try > { > List<URL> allURLs = new ArrayList<URL>(); > for (Object o : artifacts) > { > Artifact artifact = (Artifact) o; > allURLs.add(artifact.getFile().toURL()); > > } > > // TO FIX CLASSLOADER BUG > // Set up the classloader to load from all declared > artifacts in this > project > URL[] urls = new URL[allURLs.size()]; > urls = allURLs.toArray(urls); > URLClassLoader loader = new URLClassLoader(urls, > Thread.currentThread().getContextClassLoader()); > Thread.currentThread().setContextClassLoader(loader); > > // // TODO - this fix is definately NOT a > desirable solution > // // the plugin classloader will gradually > accumulate more and > more redundant stuff > // // but it works for now, although there are > duplicates being > loaded and it isn't right! > } > catch (MalformedURLException e) > { > throw new MojoExecutionException( > "Unable to access " + classDir.getAbsolutePath()); > } > > } > > > thanks -- Chris > > -- > View this message in context: > http://www.nabble.com/Do-maven-plugin-%28mojo%29-developers-ha 2C-or-do-we-need-to-build-it-up-ourselves--tp18063356p18063356.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
