On Mon, 23 Jun 2008 01:58:23 pm Jason van Zyl wrote:
> On 22-Jun-08, at 5:50 PM, Eric Rose wrote:
> > 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.
> >
> > Why is that?
>
> Because from lots of experience I know you probably don't need it.
> Make your life simple, the dependency plugin is quite powerful. If you
> determine you want to use it directly the dependency plugin is a great
> example of how to use the APIs.
>
> > Surely the dependency plugin can't be appropriate for every case
> > of artifact resolution. If the artifact resolver API isn't usable as-
> > is, or
> > is not documented fully I would expect that to be a problem to be
> > addressed.
>
> It has been in trunk, but that's not what's used on the 2.0.x line
> which is probably what you're using.

correct.

>
> > To expand on my problem, I am trying to write a wrapper around
> > IzPack so that
> > installers can be created with custom panels. A project calling my
> > plugin
> > would have configuration something like:
> >
> >  <plugin>
> >   ....
> >    <configuration>
> >      <customPanels>
> >        <customPanel>
> >          <groupId>foo.bar</groupId>
> >          <artifactId>MyCustomPanel</artifactId>
> >          <version>1.0</version>
> >        </customPanel>
> >      </customPanels>
> >    </configuration>
> >  </plugin>
> >
> > If there's a way I can call the dependency plugin programatically
> > from my
> > plugin, to pass along the parsed artifact information from the calling
> > project, I'd like to know. So far I have not found anything, hence my
> > decision to follow the documentation path that seemed to exist for
> > calling
> > the resolver directly.
>
> That's your solution. But your problem is putting some artifacts
> somewhere to be packaged up with an installer. If your requirement is
> to have all that code controlled from your plugin then use the
> resolver, but you can certainly solve your problem without it. The
> dependency plugin code would be a good place to start.

It is a requirement to do it all within the plugin. Currently I have stuff 
scattered throughout the client POM, which does make use of 
maven-dependency-plugin. I need to hide all that behind an easy-to-use 
facade - a single plugin that allows you to specify (at least) where IzPack 
is, what custom panels your installer needs and where your IzPack config is. 
Replicating the process between numerous installer projects; where you need 
to copy assorted custom panels and other assorted setup for IzPack, invoking 
IzPack, and then cleaning up afterwards can be seriously messy and fraught 
with error. The more of that I can peel away from the user, the better.


I started out looking at the code for maven-dependency-plugin, but it was so 
convoluted, that I couldn't get a handle on what it did, and how it 
initialised maven components as required. As I said, the cookbook has so far 
been the only place that spells out some basic steps on interaction with the 
maven infrastructure in a programmatic manner. If someone can give me a 
couple of pointers to more information, I would be grateful.

        <snip>

> Plugins depending on plugins is not a good thing. We learned the hard
> way with Maven 1.x where this was possible.

It certainly wouldn't be my first choice for solving my problem :)

Eric

>
> >     FooPlugin foo = new FooPlugin();
> >     foo.setBar1(xxx);
> >     foo.setBar2(yy);
> >        foo.execute();
> >
> > where setBarX() methods mirror the plugin parameters?
> >
> > By the way, there appears to be scant information on what components
> > can be
> > used and how to use them property. Is there a definitive set of
> > documentation
> > that I should be looking at? If I'm casting nasturtiums unjustly, I
> > apologise, but maven appears great from a user's perspective and
> > very hard to
> > pull apart from a programmer's perspective, and that's mainly a
> > documentation
> > issue, IMO.
> >
> > 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:
> >>> 174)
> >>>
> >>> 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-tp18040514p1
> >>>80 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]
> >
> > --
> > Eric Rose           | Don't blame me -
> > [EMAIL PROTECTED]   | I didn't vote for him.
> >
> > ***********************************************************************
> > This message contains privileged and confidential information intended
> > only for the use of the addressee named above.  If you are not the
> > intended recipient of this message you must not disseminate, copy or
> > take any action in reliance on it.  If you have received this message
> > in error please notify the sender immediately.  Any views expressed in
> > this message are those of the individual sender, except where the
> > sender specifically states them to be the views of another (including
> > a Body Corporate).
> >
> > If you wish to opt out from future messages, send an email to
> > [EMAIL PROTECTED] with the subject UNSUBSCRIBE
> > ************************************************************************
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> We all have problems. How we deal with them is a measure of our worth.
>
>   -- Unknown
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-- 
Eric Rose           | Don't blame me -
[EMAIL PROTECTED]   | I didn't vote for him.

***********************************************************************
This message contains privileged and confidential information intended
only for the use of the addressee named above.  If you are not the
intended recipient of this message you must not disseminate, copy or
take any action in reliance on it.  If you have received this message
in error please notify the sender immediately.  Any views expressed in
this message are those of the individual sender, except where the
sender specifically states them to be the views of another (including
a Body Corporate).

If you wish to opt out from future messages, send an email to
[EMAIL PROTECTED] with the subject UNSUBSCRIBE
************************************************************************

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to