You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@zenplex.com> on 2003/06/26 02:47:38 UTC
Standard method for retrieving plugin properties in plugins
Hi,
Just glancing around the plugins I see a few different ways that people
are using to reference plugin properties that belong to the plugin in
question. For example inside the java plugin there are references like:
${maven.compile.target}
${context.getVariable('maven.compile.fork'}
and in some other plugins:
${pom.getPluginContext('maven-foo-plugin').getVariable('bar')}
Which is only really needed if you're trying to get hold of a property
for in another plugin.
This is something else I would like to standardize and with the current
refactoring something like:
${plugin.getProperty('maven.compile.target')}
would work or we could simply do the
${maven.compile.target}
which is not clear as to where the property comes is used in some
places.
I am in favour in the first form as it's perfectly clear where the value
comes from and is what I would like to use in the doco.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Brett Porter <bp...@f2network.com.au>.
Jason,
Are you saying ${plugin.getProperty('maven.compile.target')} for the
current plugin, and
${pom.getPlugin('maven-foo-plugin').getProperty('bar')} for another plugin?
Sounds good to me.
That leaves ant propertys and j:set values to be the only ones
referenced as ${foo.bar}, right?
Cheers,
Brett
Jason van Zyl wrote:
> Hi,
>
> Just glancing around the plugins I see a few different ways that people
> are using to reference plugin properties that belong to the plugin in
> question. For example inside the java plugin there are references like:
>
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 26 Jun 2003 12:07 pm, Jason van Zyl wrote:
> <plugin-property plugin="xdoc" name="maven.dest.dir" value="dest.dir"/>
>
> so that would extract the 'maven.dest.dir' property from the xdoc plugin
> and place the value in 'dest.dir' for use in the current context.
Sounds good. But it may be better to name the attributes more according to
what they do or else you would need to consult documentation to figure out
which gets copied where.
<plugin-property plugin="xdoc" fromVar="maven.dest.dir" toVar="dest.dir"/>
or maybe
<plugin-property fromVar="xdoc:maven.dest.dir" toVar="dest.dir"/>
where <plugin>:<variable>
As that you could also extend this to allow setting of such properties like
<plugin-property fromVar="dest.dir" toVar="xdoc:maven.dest.dir"/>
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Brett Porter <bp...@f2network.com.au>.
out of these I prefer
<plugin-property plugin="xdoc" name="maven.dest.dir" value="dest.dir"/>
as you can probably do better error reporting and it is clearer what is
the plugin and what is the property.
- Brett
Jason van Zyl wrote:
> On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
>
>
> Another thing would probably be nice to standardize is the inter-plugin
> property retrieval. Bob's thought is a tag that we could use, something
> like:
>
> <plugin-property plugin="xdoc" name="maven.dest.dir" value="dest.dir"/>
>
> so that would extract the 'maven.dest.dir' property from the xdoc plugin
> and place the value in 'dest.dir' for use in the current context.
>
> The other we could try because jexl is basically velocity is place some
> maps in the context so we could do something like:
>
> ${plugins.xdoc.maven.dest.dir}
>
> Any preferences?
>
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2003-06-27 at 08:47, Jason van Zyl wrote:
> I can deal with our plugins, but for the sake of a sane 1.0 release and
> something we can easily document I think this is the right way to go. I
> added the cross plugin access at one point for Vincent and I admittedly
> did it to quickly. But I think in the long run the single access method
> using properly namespaced names will only be a benefit. And
> unfortunately Jexl can't handle it.
Sorry, that should be unfortunately Jexl can't handle:
Map.Map.<dotted.property>
Which is what we currently have in a lot of places.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2003-06-27 at 03:18, Rafal Krzewski wrote:
> Jason van Zyl wrote:
>
> > There will no longer be any namespace confusion as what's in a plugin is
> > completely separate. You could have the same property in many plugins
> > now and the value for the particular plugin will stay attached to the
> > plugin it belongs too. There are now separate classloaders for the
> > plugins as well.
>
> This is a good thing. Prevents obscure problems before they happen.
>
> >>In that case I agree, because I'm not sure how Velocity is going to tell
> >>between plugins, antlr and "src.dir", without thinking it needs to do
> >>getSrc().getDir()
> >
> >
> > It can't which is why I am in favour of using standard Java naming
> > conventions for properties. This also makes sense name space wise if you
> > compare:
> >
> > ${plugins.antlr.srcDir}
> >
> > as opposed to
> >
> > ${plugins.antlr.src.dir}
> >
> > This is what I've started working toward.
>
> Big + from me. Dot is obviously used as a namespace separator in
> property names, and unfortunately it is very commonly abused as
> a 'whitespace' character too.
>
> I personally also have a preference for Java naming convention,
> but lowercase_lowercase convention is also acceptable.
>
> The only downside is that almost all properites in all plugins
> will have to be changed, and this will affect the users heavily:
> each and every project.properites & build.properties file in
> existence will have to be changed to work with the new plugins.
I can deal with our plugins, but for the sake of a sane 1.0 release and
something we can easily document I think this is the right way to go. I
added the cross plugin access at one point for Vincent and I admittedly
did it to quickly. But I think in the long run the single access method
using properly namespaced names will only be a benefit. And
unfortunately Jexl can't handle it.
>
> >>, but it might work. IT also rules out having "." in a
> >>plugin name - not a big deal, but worth checking.
> >
> > We will need a standard naming convention for plugins too. Definitely no
> > "."s allowed and I haven't tried yet but I'm pretty sure I'm going to
> > run into a problem with the few plugins that have hyphens because jexl
> > is going to try and substract.
>
> Good thing too. Lowercase ASCII letters and underscore characters should
> do it IMO.
Yes, I think so.
> >>As an aside, how do you assign to the variable, or is that not allowed
> >>outside of the plugin?
> >
> > In the cases where this needs to be done you could grab hold of the Map
> > which contains the plugins properties. So, for example, if you wanted to
> > change the srcDir in the antlr plugin you would use:
> >
> > ${plugins.antlr.put( "srcDir", "/path" )}
> >
> > I agree this is not the most element solution but a tag could be made
> > too if desired. But in most cases where you just want to read the
> > property
>
> I'd suggest creating the tag right away and advertising it as a standard
> practice. This tag could have a tracing option that you could turn on
> if some other plugin messes up your properties at runtime, and you
> need to track that down.
Sounds like a good idea and the tag would be very easy to implement. It
is probably also wise to keep methods out of the Jelly if possible.
> R.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Jason van Zyl wrote:
> There will no longer be any namespace confusion as what's in a plugin is
> completely separate. You could have the same property in many plugins
> now and the value for the particular plugin will stay attached to the
> plugin it belongs too. There are now separate classloaders for the
> plugins as well.
This is a good thing. Prevents obscure problems before they happen.
>>In that case I agree, because I'm not sure how Velocity is going to tell
>>between plugins, antlr and "src.dir", without thinking it needs to do
>>getSrc().getDir()
>
>
> It can't which is why I am in favour of using standard Java naming
> conventions for properties. This also makes sense name space wise if you
> compare:
>
> ${plugins.antlr.srcDir}
>
> as opposed to
>
> ${plugins.antlr.src.dir}
>
> This is what I've started working toward.
Big + from me. Dot is obviously used as a namespace separator in
property names, and unfortunately it is very commonly abused as
a 'whitespace' character too.
I personally also have a preference for Java naming convention,
but lowercase_lowercase convention is also acceptable.
The only downside is that almost all properites in all plugins
will have to be changed, and this will affect the users heavily:
each and every project.properites & build.properties file in
existence will have to be changed to work with the new plugins.
>>, but it might work. IT also rules out having "." in a
>>plugin name - not a big deal, but worth checking.
>
> We will need a standard naming convention for plugins too. Definitely no
> "."s allowed and I haven't tried yet but I'm pretty sure I'm going to
> run into a problem with the few plugins that have hyphens because jexl
> is going to try and substract.
Good thing too. Lowercase ASCII letters and underscore characters should
do it IMO.
>>As an aside, how do you assign to the variable, or is that not allowed
>>outside of the plugin?
>
> In the cases where this needs to be done you could grab hold of the Map
> which contains the plugins properties. So, for example, if you wanted to
> change the srcDir in the antlr plugin you would use:
>
> ${plugins.antlr.put( "srcDir", "/path" )}
>
> I agree this is not the most element solution but a tag could be made
> too if desired. But in most cases where you just want to read the
> property
I'd suggest creating the tag right away and advertising it as a standard
practice. This tag could have a tracing option that you could turn on
if some other plugin messes up your properties at runtime, and you
need to track that down.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-06-26 at 17:46, Brett Porter wrote:
> I thought Vincent was saying that he thought <plugin-property
> plugin="xdoc" name="maven.dest.dir" value="dest.dir"/> was better to
> avoid namespace confusion?
There will no longer be any namespace confusion as what's in a plugin is
completely separate. You could have the same property in many plugins
now and the value for the particular plugin will stay attached to the
plugin it belongs too. There are now separate classloaders for the
plugins as well.
> In that case I agree, because I'm not sure how Velocity is going to tell
> between plugins, antlr and "src.dir", without thinking it needs to do
> getSrc().getDir()
It can't which is why I am in favour of using standard Java naming
conventions for properties. This also makes sense name space wise if you
compare:
${plugins.antlr.srcDir}
as opposed to
${plugins.antlr.src.dir}
This is what I've started working toward.
> , but it might work. IT also rules out having "." in a
> plugin name - not a big deal, but worth checking.
We will need a standard naming convention for plugins too. Definitely no
"."s allowed and I haven't tried yet but I'm pretty sure I'm going to
run into a problem with the few plugins that have hyphens because jexl
is going to try and substract.
> As an aside, how do you assign to the variable, or is that not allowed
> outside of the plugin?
In the cases where this needs to be done you could grab hold of the Map
which contains the plugins properties. So, for example, if you wanted to
change the srcDir in the antlr plugin you would use:
${plugins.antlr.put( "srcDir", "/path" )}
I agree this is not the most element solution but a tag could be made
too if desired. But in most cases where you just want to read the
property
${plugins.antlr.srcDir}
is clear I believe.
> Cheers,
> Brett
>
> Jason van Zyl wrote:
> > On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
> >
> >
> >
> >>I like the second form personally although I agree it is less
> >>understandable than the first. Thus, I would think the first is probably
> >>the best to avoid namespace confusion.
> >
> >
> > Ok, so you are in favour of the ${foo} form for both. Cool, I'll keep
> > track. After thinking about it I think I like that too.
> >
> > ${maven.compile.target}
> >
> > ${plugins.antlr.src.dir}
> >
> > If I can get this to work this is what you would prefer, yes?
> >
> >
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Brett Porter <bp...@f2network.com.au>.
I thought Vincent was saying that he thought <plugin-property
plugin="xdoc" name="maven.dest.dir" value="dest.dir"/> was better to
avoid namespace confusion?
In that case I agree, because I'm not sure how Velocity is going to tell
between plugins, antlr and "src.dir", without thinking it needs to do
getSrc().getDir(), but it might work. IT also rules out having "." in a
plugin name - not a big deal, but worth checking.
As an aside, how do you assign to the variable, or is that not allowed
outside of the plugin?
Cheers,
Brett
Jason van Zyl wrote:
> On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
>
>
>
>>I like the second form personally although I agree it is less
>>understandable than the first. Thus, I would think the first is probably
>>the best to avoid namespace confusion.
>
>
> Ok, so you are in favour of the ${foo} form for both. Cool, I'll keep
> track. After thinking about it I think I like that too.
>
> ${maven.compile.target}
>
> ${plugins.antlr.src.dir}
>
> If I can get this to work this is what you would prefer, yes?
>
>
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2003-06-27 at 02:18, dion@multitask.com.au wrote:
> If we don't have to rejig the properties for all the plugins, I'm +1 on
> the new dotted syntax.
The standard syntax would be more namespace sensible in the form of:
${plugins.antlr.srcDir}
And without changing the names you can't do it with Jexl, it just can't
handle it. There are currently 3 different ways to nab properties and
I'd like to standardize on the above format.
I doubt anyone will want to help with such a glamourous job but I will
change all the property names. With complete separation of the plugins
in terms of properties space, classloaders and Jelly contexts and making
the properties access more sensible something must change before 1.0.
What we currently have is confusing.
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
> Work: http://www.multitask.com.au
>
>
> Jason van Zyl <ja...@zenplex.com> wrote on 26/06/2003 10:31:01 PM:
>
> > On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
> >
> >
> > > I like the second form personally although I agree it is less
> > > understandable than the first. Thus, I would think the first is
> probably
> > > the best to avoid namespace confusion.
> >
> > Ok, so you are in favour of the ${foo} form for both. Cool, I'll keep
> > track. After thinking about it I think I like that too.
> >
> > ${maven.compile.target}
> >
> > ${plugins.antlr.src.dir}
> >
> > If I can get this to work this is what you would prefer, yes?
> >
> > > -Vincent
> > >
> > > >
> > > > --
> > > > jvz.
> > > >
> > > > Jason van Zyl
> > > > jason@zenplex.com
> > > > http://tambora.zenplex.org
> > > >
> > > > In short, man creates for himself a new religion of a rational
> > > > and technical order to justify his work and to be justified in it.
> > > >
> > > > -- Jacques Ellul, The Technological Society
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Standard method for retrieving plugin properties in plugins
Posted by di...@multitask.com.au.
If we don't have to rejig the properties for all the plugins, I'm +1 on
the new dotted syntax.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Jason van Zyl <ja...@zenplex.com> wrote on 26/06/2003 10:31:01 PM:
> On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
>
>
> > I like the second form personally although I agree it is less
> > understandable than the first. Thus, I would think the first is
probably
> > the best to avoid namespace confusion.
>
> Ok, so you are in favour of the ${foo} form for both. Cool, I'll keep
> track. After thinking about it I think I like that too.
>
> ${maven.compile.target}
>
> ${plugins.antlr.src.dir}
>
> If I can get this to work this is what you would prefer, yes?
>
> > -Vincent
> >
> > >
> > > --
> > > jvz.
> > >
> > > Jason van Zyl
> > > jason@zenplex.com
> > > http://tambora.zenplex.org
> > >
> > > In short, man creates for himself a new religion of a rational
> > > and technical order to justify his work and to be justified in it.
> > >
> > > -- Jacques Ellul, The Technological Society
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
RE: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-06-26 at 01:34, Vincent Massol wrote:
> I like the second form personally although I agree it is less
> understandable than the first. Thus, I would think the first is probably
> the best to avoid namespace confusion.
Ok, so you are in favour of the ${foo} form for both. Cool, I'll keep
track. After thinking about it I think I like that too.
${maven.compile.target}
${plugins.antlr.src.dir}
If I can get this to work this is what you would prefer, yes?
> -Vincent
>
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Standard method for retrieving plugin properties in plugins
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@zenplex.com]
> Sent: 26 June 2003 04:07
> To: Maven Developers List
> Subject: Re: Standard method for retrieving plugin properties in
plugins
>
> On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
> > Hi,
> >
> > Just glancing around the plugins I see a few different ways that
people
> > are using to reference plugin properties that belong to the plugin
in
> > question. For example inside the java plugin there are references
like:
> >
> > ${maven.compile.target}
> > ${context.getVariable('maven.compile.fork'}
> >
> > and in some other plugins:
> >
> > ${pom.getPluginContext('maven-foo-plugin').getVariable('bar')}
> >
> > Which is only really needed if you're trying to get hold of a
property
> > for in another plugin.
> >
> > This is something else I would like to standardize and with the
current
> > refactoring something like:
> >
> > ${plugin.getProperty('maven.compile.target')}
> >
> > would work or we could simply do the
> >
> > ${maven.compile.target}
> >
> > which is not clear as to where the property comes is used in some
> > places.
Why is not clear? Each plugin has its context, right? So it can only
come from the plugin context, no? I view it as a short form of
${plugin.getProperty(...
But it's much shorter to read and write which leads to clearer code.
> >
> > I am in favour in the first form as it's perfectly clear where the
value
> > comes from and is what I would like to use in the doco.
>
> Another thing would probably be nice to standardize is the
inter-plugin
> property retrieval. Bob's thought is a tag that we could use,
something
> like:
>
> <plugin-property plugin="xdoc" name="maven.dest.dir"
value="dest.dir"/>
>
> so that would extract the 'maven.dest.dir' property from the xdoc
plugin
> and place the value in 'dest.dir' for use in the current context.
>
> The other we could try because jexl is basically velocity is place
some
> maps in the context so we could do something like:
>
> ${plugins.xdoc.maven.dest.dir}
>
> Any preferences?
The first form is more explicit but it forces you to go through an extra
step of storing the property in yet another property...
I like the second form personally although I agree it is less
understandable than the first. Thus, I would think the first is probably
the best to avoid namespace confusion.
-Vincent
>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Standard method for retrieving plugin properties in plugins
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-06-25 at 20:47, Jason van Zyl wrote:
> Hi,
>
> Just glancing around the plugins I see a few different ways that people
> are using to reference plugin properties that belong to the plugin in
> question. For example inside the java plugin there are references like:
>
> ${maven.compile.target}
> ${context.getVariable('maven.compile.fork'}
>
> and in some other plugins:
>
> ${pom.getPluginContext('maven-foo-plugin').getVariable('bar')}
>
> Which is only really needed if you're trying to get hold of a property
> for in another plugin.
>
> This is something else I would like to standardize and with the current
> refactoring something like:
>
> ${plugin.getProperty('maven.compile.target')}
>
> would work or we could simply do the
>
> ${maven.compile.target}
>
> which is not clear as to where the property comes is used in some
> places.
>
> I am in favour in the first form as it's perfectly clear where the value
> comes from and is what I would like to use in the doco.
Another thing would probably be nice to standardize is the inter-plugin
property retrieval. Bob's thought is a tag that we could use, something
like:
<plugin-property plugin="xdoc" name="maven.dest.dir" value="dest.dir"/>
so that would extract the 'maven.dest.dir' property from the xdoc plugin
and place the value in 'dest.dir' for use in the current context.
The other we could try because jexl is basically velocity is place some
maps in the context so we could do something like:
${plugins.xdoc.maven.dest.dir}
Any preferences?
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org