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