You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Owen Jacobson <ow...@grimoire.ca> on 2011/04/29 01:27:45 UTC
Building a -classpath for a plugin, from the inside?
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
RE: Building a -classpath for a plugin, from the inside?
Posted by Martin Gainty <mg...@hotmail.com>.
adding a configuration parameter to the plugin such as additionalClasspathElements from surefire plugin would allow additonal entries to the cp
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
does this help??
Martin
______________________________________________
Note de déni et de confidentialité
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> From: owen.jacobson@grimoire.ca
> Subject: Building a -classpath for a plugin, from the inside?
> Date: Thu, 28 Apr 2011 19:27:45 -0400
> To: users@maven.apache.org
>
> 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
>
Re: Building a -classpath for a plugin, from the inside?
Posted by Jörg Schaible <jo...@scalaris.com>.
Owen Jacobson 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?
Extracts from the AbstractJaxwsMojo in the jaxws-maven-plugin at Codehaus
Mojo:
========= %< =========
List classpathFiles = project.getCompileClasspathElements();
URL[] urls = new URL[classpathFiles.size()];
StringBuffer classPath = new StringBuffer();
for ( int i = 0; i < classpathFiles.size(); ++i )
{
urls[i] = new File( (String) classpathFiles.get( i ) ).toURL().toURI();
classPath.append( (String) classpathFiles.get( i ) );
classPath.append( File.pathSeparatorChar );
}
URLClassLoader cl = new URLClassLoader( urls,
Thread.currentThread().getContextClassLoader() );
Thread.currentThread().setContextClassLoader( cl );
System.setProperty( "java.class.path", classPath.toString() );
========= %< =========
Obviously you should restore the classloader and system property later on.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Building a -classpath for a plugin, from the inside?
Posted by 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
Re: Building a -classpath for a plugin, from the inside?
Posted by Ryan Connolly <ry...@gmail.com>.
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
>>
>>
>
Re: Building a -classpath for a plugin, from the inside?
Posted by Ryan Connolly <ry...@gmail.com>.
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
>
>