Re: Standard method for retrieving plugin properties in plugins
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. Which is what we currently have in a lot of places. -- 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
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: [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
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 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
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
On Thu, 2003-06-26 at 17:46, Brett Porter wrote: > I thought Vincent was saying that he thought 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 [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
I thought Vincent was saying that he thought 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standard method for retrieving plugin properties in plugins
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
> -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > 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: > > > > 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 > [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]
Re: Standard method for retrieving plugin properties in plugins
out of these I prefer 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: 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]
Re: Standard method for retrieving plugin properties in plugins
On Thu, 26 Jun 2003 12:07 pm, Jason van Zyl wrote: > > > 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. or maybe where : As that you could also extend this to allow setting of such properties like -- 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
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
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: 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]
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 [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]