You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by upstreamnet <up...@yahoo.com> on 2008/06/23 08:38:50 UTC
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.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
--
View this message in context: http://www.nabble.com/Do-maven-plugin-%28mojo%29-developers-have-access-to-a-classloader-based-on-%24%7Bproject.artifacts%7D%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@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Do maven plugin (mojo) developers have access to a classloader based on ${project.artifacts}, or do we need to build it up ourselves?
Posted by Bernhard David <da...@elca.ch>.
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@yahoo.com]
> Sent: 23 June 2008 08:39
> To: users@maven.apache.org
> 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.
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=flu
xion&path=%2Ftrunk%2Fstack%2Fgenerate-beans-plugin%2Fsrc%2Fmain%>
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
ve-access-to-a-classloader-based-on-%24%7Bproject.artifacts%7D%>
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@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org