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

[Owen Jacobson <ow...@grimoire.ca>]

Thanks, Ryan. This turned out to be exactly the solution I needed:

https://bitbucket.org/ojacobson/apacheds-maven-plugin/changeset/fcb7d7b66a41

-o

On 2011-04-29, at 9:00 AM, Ryan Connolly wrote:

> 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 <ry...@gmail.com> 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 <ow...@grimoire.ca>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: 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