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