No - it should work for both.
- Brett
On 11/9/05, David H. DeWolf <[EMAIL PROTECTED]> wrote:
> Is there a reason why that would work for ArtifactFactory but not for
> ArtifactResolver?
>
> Brett Porter wrote:
> > 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.ArtifactResolver}"
> >>>>
> >>>>@parameter
> >>>>expression="${component.org.apache.maven.artifact.factory.ArtifactFactory}"
> >>>>
> >>>>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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
