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]
