Whoa. What form is deprecated? @parameter
expression="${someExpression}"?
That's what the Mojo API Specification doc says to use. There's nothing
about @component on that page at all.
-----Original Message-----
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 08, 2005 10:15 PM
To: Maven Users List
Subject: Re: [M2] Injecting ArtifactFactory and ArtifactResolver into
Plugin
The @component tag is in 2.0. The other form is deprecated.
/**
* @component
*/
private ArtifactFactory factory;
(role is only necessary for a list of components or if it differs from
the type)
- Brett
On 11/9/05, David H. DeWolf <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
> > On Tue, 2005-11-08 at 22:08 -0500, David H. DeWolf wrote:
> >
> >>I'm developing a plugin which requires an ArtifactFactory and
> >>ArtifactResolver and am attempting to get them injected. I have
> >>tried two approaches:
> >>
> >>@component
role="org.apache.maven.artifact.resolver.ArtifactResolver"
> >>@component role="org.apache.maven.artifact.factory.ArtifactFactory"
> >
> >
> > What are you trying to do exactly?
>
> I'm attempting to create a plugin which will automate the installation
> of the Pluto Portalinto an app server. My requirements go beyond
> simply deploying the war as Pluto requires some configuration,
> integration with other webapps, and the deployment of shared and
> endorsed artifacts into the app server.
>
> I currently have a version of the plugin that will complete this task
> when executed from within a utilities subproject (using the "just
> created" artifacts). I'd like to modify the plugin so that the
> installation can use artifacts in the repository so that users don't
> have to check out the source code first. I'd also prefer not to have
> the artifacts embeded within the plugin.
>
>
> Thanks,
>
> David
>
> >
> >
> >>and
> >>
> >>@parameter
>
>>expression="${component.org.apache.maven.artifact.resolver.ArtifactRes
olver}"
> >>
> >>@parameter
>
>>expression="${component.org.apache.maven.artifact.factory.ArtifactFact
ory}"
> >>
> >>It appears the later approach is appropriate for 2.0 and the former
> >>is appropriate for the current trunk, however, I've tried both and
> >>am having no luck with either approach.
> >>
> >>Both approaches result in a NullPointerException which is hidden by
> >>a previously fixed bug in DiagnosisUtils (patch applied against the
> >>trunk) in which a secondary NullPointer is thrown if an exception
message is null.
> >>
> >>Any ideas?
> >>
> >>Thanks,
> >>
> >>David
> >>
> >>
> >>--------------------------------------------------------------------
> >>- To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
