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 <ryn...@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
> <owen.jacob...@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-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
