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]
