Eric,
I'm the author of the dependency plugin and I agree it's a little
convoluted now but I didn't want to refactor again before 2.0. It
shouldn't be too bad though because I tried to encapsulate the majority
of the real work in super classes to reduce the code across all the
mojos. Some of the filters and other things I did manage to pull out to
another shared component, but the resolution code is not...probably it
could be.
If I were going to try to attempt this now without refactoring, I would
copy the dependency plugin, extend the AbstractFromConfiguration with
your class and toss everything else that isn't used. The ArtifactItem
bean is where the config is pulled in from the pom and the
AbstractFromConfiguration does all the processing for you. If you look
at the execute for copy, it can't get much easier as a consumer of this
abstract class:
public void execute()
throws MojoExecutionException
{
This does all the processing:
ArrayList theArtifactItems = getProcessedArtifactItems(
this.stripVersion );
Walk the list:
Iterator iter = theArtifactItems.iterator();
while ( iter.hasNext() )
{
ArtifactItem artifactItem = (ArtifactItem) iter.next();
Certain rules in the ArtifactItem decide if processing is
needed...like if the file is already up to date, etc. This is done via
filters and marker files because unpacked files aren't as easy to check.
if ( artifactItem.isNeedsProcessing() )
{
Then just copy it.
copyArtifact( artifactItem );
}
else
{
this.getLog().info( artifactItem + " already exists in "
+ artifactItem.getOutputDirectory() );
}
}
}
Jason's advice to avoid the resolver api directly is probably two
fold...first, it's quite frankly not an API. There is no single method
to deal with getting what you want. The code I have is a close
approximation but there are some missing things, first it doesn't handle
ranges and second it doesn't find things in sibling projects not already
installed. This means you effectively need to figure out the core and
recode 99% of what's in there...and trust me that's no small task. The
second reason is because the maven-artifact code is significantly
reworked in 2.1 and you don't want to tie yourself too closely to the
mess that's here. Again it stems from the fact that what's there really
isn't an API...you're hooking in all over the place.
--Brian
-----Original Message-----
From: Eric Rose [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 22, 2008 4:21 AM
To: Maven Users List
Subject: Re: A question about artifact resolution
On Sun, 22 Jun 2008 06:02:48 am Jason van Zyl wrote:
> Use the maven-dependency-plugin, it can retrieve artifacts and place
> them so that you can subsequently process them. I suggest staying away
> from the artifact resolver directly.
Then I need to know how to drive maven-dependency-plugin programatically
within another plugin.
Basically I'm tring to drive IzPack with custom panels that need to be
copied into the correct location for IzPack to use. The panels would be
artifacts that would be specified using something like the following
config structure in the project that invoked my plugin:
<configuration>
<izPackDir>/usr/local/IzPack-3.10.2/</izPackDir>
<input>src/main/izpack/izpack-config.xml</input>
<customPanels>
<customPanel>
<groupId>foo.bar</groupId>
<artifactId>DoSomethingPanel</artifactId>
<version>1.0</version>
</customPanel>
</customPanels>
</configuration>
I searched but could find no documentation that explained how I might do
that with the dependency plugin, which is why the approach in the
cookbook looked usable.
By the way...why stay away from directly using the artifact resolution
API?
Isn't it meant to be used externally? Since I could find so little
documentation on using maven components in a plugin, it strikes me that
someone who knows the internals should make a concise and complete guide
listing all the components and interfaces that people like me can use,
rather than the vague hints out there.
If I did miss some obvious documentation, then I apologise for casting
nasturtiums. Maven's been great from a user's perspective, but harder to
dissect from a developer's perspective.
Eric
>
> On 20-Jun-08, at 7:59 PM, ericr wrote:
> > Hi,
> >
> > I'm trying to develop a plugin in which I want to resolve an
> > artifact so that I can copy it somewhere special before using it.
> > Not knowing how (or if it's even possible) to embed the dependency
> > plugin's resolution functionality, I decided to take what seemed
> > like a simpler approach and perform the basic resolution myself, as
> > according to
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook.
> >
> > Unfortunately I get the following NPE:
> >
> > Caused by: java.lang.NullPointerException
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:129)
> > at
> > org
> > .apache
> > .maven
> > .artifact
> > .resolver
> > .DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
> > at
> > com
> > .izforge
> > .izpack.maven.plugins.IzPackMojo.copyCustomPanels(IzPackMojo.java:17
> > 4)
> >
> > The code snippet that I wrote is as follows:
> > /** @component */
> > private org.apache.maven.artifact.factory.ArtifactFactory
> > artifactFactory;
> >
> > /** @component */
> > private org.apache.maven.artifact.resolver.ArtifactResolver
> > resolver;
> >
> > someMethod() {
> > Artifact panelArtifact =
> > artifactFactory.createArtifactWithClassifier(groupId, artifactId,
> > version, "jar", "");
> > try
> > {
> > resolver.resolve(panelArtifact, remoteRepositories,
> > localRepository);
> >
> > Do I need to create a variable in my plugin to store a component
> > similar to the the ArtifactFactory and ArtifactResolver mentioned in
> > the cookbook? Is there a better set of documentation that explains
> > how to accomplish such tasks?
> >
> > Eric
> >
> > --
> > View this message in context:
> >
http://www.nabble.com/A-question-about-artifact-resolution-tp18040514p18
0
> >40514.html Sent from the Maven - Users mailing list archive at
Nabble.com.
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
"Anything that is in the world when you're born is normal and ordinary
and is
just a natural part of the way the world works. Anything that's invented
between when you're fifteen and thirty-five is new and exciting and
revolutionary and you can probably get a career in it. Anything invented
after you're thirty-five is against the natural order of things."
-- Douglas Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
