RE: Standard method for retrieving plugin properties in plugins

[dion]

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 [EMAIL PROTECTED] 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
   [EMAIL PROTECTED]
   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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 -- 
 jvz.
 
 Jason van Zyl
 [EMAIL PROTECTED]
 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Standard method for retrieving plugin properties in plugins

[Rafal Krzewski]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Standard method for retrieving plugin properties in plugins

[Jason van Zyl]

On Fri, 2003-06-27 at 02:18, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  -- 
  jvz.
  
  Jason van Zyl
  [EMAIL PROTECTED]
  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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standard method for retrieving plugin properties in plugins

[Jason van Zyl]

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
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standard method for retrieving plugin properties in plugins

[Brett Porter]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standard method for retrieving plugin properties in plugins

[Peter Donald]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Standard method for retrieving plugin properties in plugins

[Brett Porter]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]