You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Chris Berry <ch...@gmail.com> on 2005/08/24 17:08:45 UTC

[m2] plugin.getDependencyPath

Hi,
In the bad old days of Jelly, we could type something like::
plugin.getDependendcyPath( 'axis:ant' );
And you got back the full path to a JAR -- so we could use it as::
  <ant:path id="axis.classpath">
    <ant:pathelement path="${plugin.getDependencyPath('axis:axis')}"/>
Is there an equivalent helper function like this for Java??

BTW: FWIW: I have no interest in using Marmalade. I want to use *only*
Java + Ant when developing my plugins. In fact, I plan to do as much
as possible with Ant and simply fire it from the Maven plugin
structure. There is no reason to reinvent the wheel. Ant provides
Tasks to do probably 95% of what I need done. Is well understood, well
supported, and well documented. I see this sort of marraige between
Maven and Ant as powerful combination.

Thanks,
-- Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] plugin.getDependencyPath

Posted by Kenney Westerhof <fo...@neonics.com>.
On Wed, 24 Aug 2005, Chris Berry wrote:

> > One thing we're considering adding to m2 in the very near term is the
> > concept of dependencies that are tied directly to a plugin definition.
>
> Don't we already have this?? I have dependencies defined for my plugin
> and they are all there when I call my Ant tasks (using an extended
> version of AbstractAntMojo). I have verified this.

The difference is that the project USING the plugin can define jars that
are included in the _plugin_ classpath ONLY. So you could for instance
enhance the antrun plugin with regexp filemappers by including
jakarta-regexp there. Right now the xdoclet plugin (using the antrun
plugin) has to define ALL xdoclet jars (xdoclet modules), so that any user
can use any ejb doclet task. However, there are a lot of them and most are
not used, so I'd like to only include the core libs (xjavadoc, xdoclet
'core' and some core deps). But that's just one usecase.

[snip on plugin.getArtifactMap]

> Unfortunately, this doesn't really work in my case. Say I have an Ant
> build file named "axis.xml" and I bundle this into my Plugin JAR. I
> cannot access this as a File. Yes, it has a path in the URL sense (i.e
> jar:/...) But Ant wants a regular old file that I can get an absolute
> path to. (BTW: Ant is just an example. The same could hold true for
> many other situations)

So you're building a mojo that executes a built-in build.xml file?
Why don't you hardcode the tasks in the mojo?
Another solution is to run that file using the ant api to parse it:

System.setProperty(
  "org.apache.tools.ant.ProjectHelper",
  "org.apache.tools.ant.helper.ProjectHelper2" // this one has URL support
);

Project proj = new Project(); // plus some initialization
ProjectHelper.getProjectHelper().parse( project, buildfileUrl );


If you use the 'ant' task (or subant..?) you can't let it inherit
everything - the properties are resolved using reflection on the
MavenProject etc., and the inheritance mechanism copies all properties to
the child ant 'process', but as each property is evaluated at runtime,
there's no list to copy.



>
> Is there any way to bundle files (such as axis.xml) into the
> repository -- such that I could access it directly as,say,
> ${localRepository}/blah/plugins/axis-plugin/1.0-SNAPSHOT/axis.xml

Nope. The fact that ant can't handle URL's is ant's fault - it could just
as easily work with URLs instead of files.. ;)

> Of course, I could unjar the Plugin into /target -- but that seems
> like a hack...

It's not forbidden to make workarounds to use 3rd party libs..
You could use getResource() to get the url of the axis.xml,
and store just that file in target/...

> Thanks for all your help & insight,

You too :)

Btw, could you send me a patch (or create a JIRA and attach it) for your
fix on making <echo> work? The only solution I saw was to set the 'stdout'
stream to System.err..

-- Kenney

> Cheers,
> -- Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] plugin.getDependencyPath

Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Berry wrote:
<snip/>

|>One thing we're considering adding to m2 in the very near term is the
|>concept of dependencies that are tied directly to a plugin definition.
|
|
| Don't we already have this?? I have dependencies defined for my plugin
| and they are all there when I call my Ant tasks (using an extended
| version of AbstractAntMojo). I have verified this.
|

What I'm talking about is per-project dependencies for a given plugin.
For example, the xdoclet plugin may only specify the dependencies it
needs to run the engine. If you, as the plugin user, want to have
xdoclet generate an EJB deployment descriptor, you might include the
xdoclet-ejb dependency in your definition of the xdoclet plugin - within
your project. This would allow people to resolve only the xdoclet
artifacts that they really need, rather than the sum total of modules
that xdoclet provides...a collection which would quickly fall out of
date as third parties might write new modules.

NOTE: This is not a question of extending one plugin with another, in
order to redefine the dependencies. This is customizing a list of
optional *additional* dependencies for a given plugin for your project
to use.

<snip/>

| Unfortunately, this doesn't really work in my case. Say I have an Ant
| build file named "axis.xml" and I bundle this into my Plugin JAR. I
| cannot access this as a File. Yes, it has a path in the URL sense (i.e
| jar:/...) But Ant wants a regular old file that I can get an absolute
| path to. (BTW: Ant is just an example. The same could hold true for
| many other situations)

It's a bit clunky, but if you're trying to do this from a java-based
mojo (i.e. not from an ant script or the antrun plugin's configuration),
you can try the following:

// note: there are better ways to do this next line...but this generally
// works.
ClassLoader cl = getClass().getClassLoader();
URL resource = cl.getResource("/path/to/resource/in/classpath");
File concreteFile = new File( resource.getPath() );

|
| Is there any way to bundle files (such as axis.xml) into the
| repository -- such that I could access it directly as,say,
| ${localRepository}/blah/plugins/axis-plugin/1.0-SNAPSHOT/axis.xml

It is possible to do that sort of thing, but it means making the
axis.xml some sort of first-class artifact to be "built" and deployed.
It's a bit of a hack...

|
| Of course, I could unjar the Plugin into /target -- but that seems
| like a hack...

I think you'll find the trick above will be a simpler solution, actually...

Cheers,

- -john

|
| Thanks for all your help & insight,
| Cheers,
| -- Chris
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDDQ0MK3h2CZwO/4URAhAFAJ9zaRW2n1XJeXxJieaqdBe/i9V+7wCZAcHu
AKQpiSNvGNIcUoE7a/Phvbo=
=kNot
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] plugin.getDependencyPath

Posted by Chris Berry <ch...@gmail.com>.
Comments inline.
Thanks,
-- Chris 

On 8/24/05, John Casey <jd...@commonjava.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One thing we're considering adding to m2 in the very near term is the
> concept of dependencies that are tied directly to a plugin definition.

Don't we already have this?? I have dependencies defined for my plugin
and they are all there when I call my Ant tasks (using an extended
version of AbstractAntMojo). I have verified this.


> As for locating plugin resources, it depends on what you're looking for.
> If it's bundled with the plugin or one of its dependencies, you should
> be able to use ClassLoader.getResource(..) to retrieve it by name. OTOH,
> if you're trying to get the path to one of the plugin dependencies, you
> can execute something similar to the following:
> 
> /**
> ~ * @parameter expression="${plugin.artifactMap}"
> ~ * @required
> ~ * @readonly
> ~ */
> private Map pluginArtifacts;
> public void execute() {
> ~  String key = ArtifactUtils.versionlessKey( "depGroupId", "depArtifactId" );
> ~  Artifact artifact = (Artifact) pluginArtifacts.get( key );
> ~  File depPath = artifact.getFile();
> 
> Does this answer your question, or am I misunderstanding?

Unfortunately, this doesn't really work in my case. Say I have an Ant
build file named "axis.xml" and I bundle this into my Plugin JAR. I
cannot access this as a File. Yes, it has a path in the URL sense (i.e
jar:/...) But Ant wants a regular old file that I can get an absolute
path to. (BTW: Ant is just an example. The same could hold true for
many other situations)

Is there any way to bundle files (such as axis.xml) into the
repository -- such that I could access it directly as,say,
${localRepository}/blah/plugins/axis-plugin/1.0-SNAPSHOT/axis.xml

Of course, I could unjar the Plugin into /target -- but that seems
like a hack...

Thanks for all your help & insight,
Cheers,
-- Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] plugin.getDependencyPath

Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One thing we're considering adding to m2 in the very near term is the
concept of dependencies that are tied directly to a plugin definition.
This is important for several use cases, not the least of which being
the use of non-core ant task libraries. Another use case might be the
inclusion of xdoclet modules, and yet another a testing harness for
integration testing an application.

With this feature, you'd only have to define the antrun plugin, along
with the axis dependency directly under the plugin definition. Then,
your ant script should be able to find the axis tasks in the plugin's
classpath.

As for locating plugin resources, it depends on what you're looking for.
If it's bundled with the plugin or one of its dependencies, you should
be able to use ClassLoader.getResource(..) to retrieve it by name. OTOH,
if you're trying to get the path to one of the plugin dependencies, you
can execute something similar to the following:

/**
~ * @parameter expression="${plugin.artifactMap}"
~ * @required
~ * @readonly
~ */
private Map pluginArtifacts;

public void execute()
{
~  String key = ArtifactUtils.versionlessKey( "depGroupId", 								
"depArtifactId" );

~  Artifact artifact = (Artifact) pluginArtifacts.get( key );

~  File depPath = artifact.getFile();

~  .
~  .
~  .
}

Does this answer your question, or am I misunderstanding?

- -john

Chris Berry wrote:
| Hi Kenney,
| I am using your plugin. Thanks. In fact, I've already extended it to
| allow it to set Ant's message level (so you can see Ant's <echo> when
| you need to).
|
| I believe that Ant + Maven is the sweet spot. What I'm trying to
| discern is the cleanest way to accomplish this.
|
| Say you want to use an "extended Ant" -- pulling in, say, the Axis Ant
| Tasks, or the ant-contrib Tasks, or whatever. I'm thinking that I will
| simply extend AbstractAntMojo with, say, AxisAntMojo. This will have
| the proper dependencies (axis:ant, etc)  and when I call <ant
| inheritAll="true" inheritRefs="true" antfile="" > -- then I should be
| able to find these Tasks on the inherited Classpath (right??)
|
| I'm hoping that I will be able to ask the Plugin for it's resources --
| so that I can find the Ant buildfile easily. I'm still figuring it
| out...
|
| Thanks again,
| -- Chris
|
| On 8/24/05, Kenney Westerhof <fo...@neonics.com> wrote:
|
|>On Wed, 24 Aug 2005, Chris Berry wrote:
|>
|>Hi,
|>
|>In m2 you just specify that jar as a dependency in the pom of the plugin.
|>It's then automatically added to the runtime classpath of that plugin's
|>execution environment. Further, you can access the Plugin object and
|>it's properties in a Mojo.
|>
|>Btw, if you plan to use ant in your plugins, have a look at the
|>maven-antrun-plugin. If you plan to use it, you should make your plugin
|>depend upon it, and extend AbstractAntTask. You can then create tasks,
|>add them to a Target object, and execute them (using a parent method).
|>(the plugin is part of the m2 svn repository).
|>
|>-- Kenney
|>
|>
|>>Hi,
|>>In the bad old days of Jelly, we could type something like::
|>>plugin.getDependendcyPath( 'axis:ant' );
|>>And you got back the full path to a JAR -- so we could use it as::
|>>  <ant:path id="axis.classpath">
|>>    <ant:pathelement path="${plugin.getDependencyPath('axis:axis')}"/>
|>>Is there an equivalent helper function like this for Java??
|>>
|>>BTW: FWIW: I have no interest in using Marmalade. I want to use *only*
|>>Java + Ant when developing my plugins. In fact, I plan to do as much
|>>as possible with Ant and simply fire it from the Maven plugin
|>>structure. There is no reason to reinvent the wheel. Ant provides
|>>Tasks to do probably 95% of what I need done. Is well understood, well
|>>supported, and well documented. I see this sort of marraige between
|>>Maven and Ant as powerful combination.
|>>
|>>Thanks,
|>>-- Chris
|>>
|>>---------------------------------------------------------------------
|>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
|>>For additional commands, e-mail: users-help@maven.apache.org
|>>
|>>
|>
|>--
|>Kenney Westerhof
|>http://www.neonics.com
|>GPG public key: http://www.gods.nl/~forge/kenneyw.key
|>
|>---------------------------------------------------------------------
|>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
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDDMqEK3h2CZwO/4URAp42AJ9Zzk5jbQtWStXNlTX6UPZztxf3yACfWlaf
tSzvsHb6CfBP9SQB8ZIOf1M=
=IdwA
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] plugin.getDependencyPath

Posted by Chris Berry <ch...@gmail.com>.
Hi Kenney,
I am using your plugin. Thanks. In fact, I've already extended it to
allow it to set Ant's message level (so you can see Ant's <echo> when
you need to).

I believe that Ant + Maven is the sweet spot. What I'm trying to
discern is the cleanest way to accomplish this.

Say you want to use an "extended Ant" -- pulling in, say, the Axis Ant
Tasks, or the ant-contrib Tasks, or whatever. I'm thinking that I will
simply extend AbstractAntMojo with, say, AxisAntMojo. This will have
the proper dependencies (axis:ant, etc)  and when I call <ant
inheritAll="true" inheritRefs="true" antfile="" > -- then I should be
able to find these Tasks on the inherited Classpath (right??)

I'm hoping that I will be able to ask the Plugin for it's resources --
so that I can find the Ant buildfile easily. I'm still figuring it
out...

Thanks again,
-- Chris 

On 8/24/05, Kenney Westerhof <fo...@neonics.com> wrote:
> On Wed, 24 Aug 2005, Chris Berry wrote:
> 
> Hi,
> 
> In m2 you just specify that jar as a dependency in the pom of the plugin.
> It's then automatically added to the runtime classpath of that plugin's
> execution environment. Further, you can access the Plugin object and
> it's properties in a Mojo.
> 
> Btw, if you plan to use ant in your plugins, have a look at the
> maven-antrun-plugin. If you plan to use it, you should make your plugin
> depend upon it, and extend AbstractAntTask. You can then create tasks,
> add them to a Target object, and execute them (using a parent method).
> (the plugin is part of the m2 svn repository).
> 
> -- Kenney
> 
> > Hi,
> > In the bad old days of Jelly, we could type something like::
> > plugin.getDependendcyPath( 'axis:ant' );
> > And you got back the full path to a JAR -- so we could use it as::
> >   <ant:path id="axis.classpath">
> >     <ant:pathelement path="${plugin.getDependencyPath('axis:axis')}"/>
> > Is there an equivalent helper function like this for Java??
> >
> > BTW: FWIW: I have no interest in using Marmalade. I want to use *only*
> > Java + Ant when developing my plugins. In fact, I plan to do as much
> > as possible with Ant and simply fire it from the Maven plugin
> > structure. There is no reason to reinvent the wheel. Ant provides
> > Tasks to do probably 95% of what I need done. Is well understood, well
> > supported, and well documented. I see this sort of marraige between
> > Maven and Ant as powerful combination.
> >
> > Thanks,
> > -- Chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
> 
> ---------------------------------------------------------------------
> 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: [m2] plugin.getDependencyPath

Posted by Kenney Westerhof <fo...@neonics.com>.
On Wed, 24 Aug 2005, Chris Berry wrote:

Hi,

In m2 you just specify that jar as a dependency in the pom of the plugin.
It's then automatically added to the runtime classpath of that plugin's
execution environment. Further, you can access the Plugin object and
it's properties in a Mojo.

Btw, if you plan to use ant in your plugins, have a look at the
maven-antrun-plugin. If you plan to use it, you should make your plugin
depend upon it, and extend AbstractAntTask. You can then create tasks,
add them to a Target object, and execute them (using a parent method).
(the plugin is part of the m2 svn repository).

-- Kenney

> Hi,
> In the bad old days of Jelly, we could type something like::
> plugin.getDependendcyPath( 'axis:ant' );
> And you got back the full path to a JAR -- so we could use it as::
>   <ant:path id="axis.classpath">
>     <ant:pathelement path="${plugin.getDependencyPath('axis:axis')}"/>
> Is there an equivalent helper function like this for Java??
>
> BTW: FWIW: I have no interest in using Marmalade. I want to use *only*
> Java + Ant when developing my plugins. In fact, I plan to do as much
> as possible with Ant and simply fire it from the Maven plugin
> structure. There is no reason to reinvent the wheel. Ant provides
> Tasks to do probably 95% of what I need done. Is well understood, well
> supported, and well documented. I see this sort of marraige between
> Maven and Ant as powerful combination.
>
> Thanks,
> -- Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org