Re: Building a -classpath for a plugin, from the inside?

Owen: I think my previous reply got it half right:

    /**
     * @parameter expression="${plugin.artifacts}"
     * @required
     * @readonly
     */
    private List<Artifact> pluginArtifacts;


        StringBuilder sb = new StringBuilder();
        for (Artifact dep : pluginArtifacts)
        {
            sb.append(dep.getFile().toURI()).append(File.pathSeparator);
        }
        getLog().info("Plugin CP = " + sb.toString());



On Thu, Apr 28, 2011 at 9:57 PM, Ryan Connolly <[EMAIL PROTECTED]> wrote:

> Owen:
>
> As far as getting a nice pre-crafted classpath element string from the
> plugin's dependencies, I am not aware of an API call that will do that like
> we can for MavenProject classpaths (project.getRuntimeClasspathElements(),
> etc.).  However, the plugin's dependencies are available in the following
> ways (maybe more):
>
>     /**
>      * @parameter expression="${plugin.artifacts}"
>      * @required
>      */
>     private List<Artifact> pluginArtifacts;
>
>     /**
>      * @parameter expression="${plugin.dependencies}"
>      * @required
>      */
>     private List<Dependency> pluginDependencies;
>
> I think the classpath would need to be constructed by using the dependency
> info from above and resolving the artifacts from a repository as
> demonstrated in the following blog post.
>
> http://blogs.webtide.com/janb/entry/extending_the_maven_plugin_classpath
>
> Hope that helps.  If others know of a better way to accomplish this I would
> be interested in this as well.
>
>
> -Ryan
>
>
>
> On Thu, Apr 28, 2011 at 7:27 PM, Owen Jacobson <[EMAIL PROTECTED]>wrote:
>
>> Hi folks,
>>
>> I'm working on upgrading a Maven plugin that runs Apache DS[0] to use the
>> latest version of their software. Unfortunately, the latest version of their
>> software does something slightly slack-jawed on startup: it inspects the
>> java.class.path system property to locate JARs that contain core LDAP
>> schemata. There is no alternate loader mechanism.
>>
>> When this happens inside a plugin, the java.class.path system property
>> contains one JAR: Maven's own launcher JAR.
>>
>> I think the shortest path from where I am to working software is to fake
>> up java.class.path before running Apache DS and then to reset it back to its
>> "real" value after the server starts. However, in order to do this, I need
>> to build a classpath-like string containing the JARs Apache DS needs.
>>
>> These JARs are already listed in the plugin's dependencies (and when the
>> plugin runs, are available in the local repository). I'd like to use that
>> information if possible, rather than hard-coding specific JAR names into the
>> plugin. However, after spending half the day looking through various
>> existing plugins, I'm no closer to doing this than I was this morning.
>>
>> 1. Is there a shortcut I missed that produces exactly the string (or list
>> of JARs) I need?
>> 2. If not, is there a reasonable way to obtain the dependency artifacts
>> for a plugin?
>> 3. If not, what's a better solution that doesn't involve patching Apache
>> DS?
>>
>> -o
>>
>> [0] https://bitbucket.org/ojacobson/apacheds-maven-plugin/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>