Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
normal expressions traverse some part of the runtime build model, like
MavenProject, Settings, etc. Component expressions are a special syntax
which causes the expression evaluator to resolve the expression by
looking up the component's role in the Plexus container instance which
loaded the plugin.
David Jackman wrote:
| Then I have to ask: What's a component expression? What's the
| different between that and a regular expression? (not THAT kind of
| regular expression :)
|
| -Original Message-
| From: Brett Porter [mailto:[EMAIL PROTECTED]
| Sent: Wednesday, November 09, 2005 7:31 PM
| To: Maven Users List
| Subject: Re: [M2] Injecting ArtifactFactory and ArtifactResolver into
| Plugin
|
| expressions are fine, component expressions are deprecated. It's true
| that it needs to be updated on the site.
|
| - Brett
|
| On 11/10/05, David Jackman [EMAIL PROTECTED] wrote:
|
|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.
|
|
|
| -
| 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]
|
|
|
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDc3XmK3h2CZwO/4URArsjAJ4l/1fT0TNo8FwHL0ovd9Ln2chILACggdcn
Yt9ut/zgX+oPvyDmlEeBB2Q=
=Q2zu
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
On Tue, 2005-11-08 at 22:36 -0500, David H. DeWolf wrote: 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. Are you strictly interested in creating a plug-in or are you interested in making a tool that you could use from a different environment, say an Eclipse plug-in? If you are then I would suggest taking a look at the embedder. You could create something with the embedder and then wrap the resulting tool you create in a mojo to make it work within Maven 2.x. http://maven.apache.org/guides/mini/guide-embedding-m2.html Inside a mojo you would then use the @component tag to pull in the embedder but that's the only component you would need as the embedder is really a facade over all the features of Maven we would like to expose to tool integrators. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
Hmmm. Definately a possibility. Thanks for the hint! David On 11/9/05, Jason van Zyl [EMAIL PROTECTED] wrote: On Tue, 2005-11-08 at 22:36 -0500, David H. DeWolf wrote: 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. Are you strictly interested in creating a plug-in or are you interested in making a tool that you could use from a different environment, say an Eclipse plug-in? If you are then I would suggest taking a look at the embedder. You could create something with the embedder and then wrap the resulting tool you create in a mojo to make it work within Maven 2.x. http://maven.apache.org/guides/mini/guide-embedding-m2.html Inside a mojo you would then use the @component tag to pull in the embedder but that's the only component you would need as the embedder is really a facade over all the features of Maven we would like to expose to tool integrators. -- jvz. Jason van Zyl jason at maven.org http://maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
On Wed, 2005-11-09 at 09:54 -0500, David H. DeWolf wrote: Hmmm. Definately a possibility. Thanks for the hint! If you think you might eventually want tooling then you definitely want to go the route of the embedder. David On 11/9/05, Jason van Zyl [EMAIL PROTECTED] wrote: On Tue, 2005-11-08 at 22:36 -0500, David H. DeWolf wrote: 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. Are you strictly interested in creating a plug-in or are you interested in making a tool that you could use from a different environment, say an Eclipse plug-in? If you are then I would suggest taking a look at the embedder. You could create something with the embedder and then wrap the resulting tool you create in a mojo to make it work within Maven 2.x. http://maven.apache.org/guides/mini/guide-embedding-m2.html Inside a mojo you would then use the @component tag to pull in the embedder but that's the only component you would need as the embedder is really a facade over all the features of Maven we would like to expose to tool integrators. -- jvz. Jason van Zyl jason at maven.org http://maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
expressions are fine, component expressions are deprecated. It's true
that it needs to be updated on the site.
- Brett
On 11/10/05, David Jackman [EMAIL PROTECTED] wrote:
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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
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]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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?
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]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Injecting ArtifactFactory and ArtifactResolver into Plugin
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]
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.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]
