forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [PROPOSAL] Plugin and themes naming convention
Date Fri, 10 Feb 2006 14:14:10 GMT
Thorsten Scherler wrote:
> El vie, 10-02-2006 a las 13:04 +0000, Ross Gardler escribió:
>>Plugins are called something like:
>>i.e. "plugin" is singular
>>But we have two themes which:
>>i.e. "theme" and "themes" is used
>>I propose that we normalise on the existing naming convention used in 
>>plugins, i.e. we use "theme" (singular)
> -1 for theme.
> +1 for normalise.
> Since core is providing not only *one* theme (singular) but at least 3
> (coat, pelt, common) it makes more sense to call theme packages
> "org.apache.forrest.themes.x".

That is true for themes.core, but (probably) not true for third party 
themes, which will be singular, and hopefully more common.

More importantly, the plural is different to the plugin convention, 
which serves to confuse. It is this confusion I am trying to avoid.

>>On a related issue. We have no consistency in the naming of plugins.
>>I have tried to follow the Java convention of lower case for the 
>>"package" names and Camel case for the plugin name:
>>i.e. org.apache.forrest.plugin.input.FooBar
>>I propose that new releases of plugins should all conform to the camel 
>>case usage. We'll keep the current naming for already released plugins.
> hmm, I find it harder to use the Uppercase variant on linux and since
> java packages do not use uppercase in package names (e.g. package
> org.apache.lenya.transaction;).
> See above, I see plugins more as a packages and I am not very happy with
> naming them org.apache.forrest.plugin.input.FooBar because for me that
> is a package and not a Class.

Yeah, I see your point, I interpret it the other way around A package 
name relates to a bunch of related classes, a class is not necessarily a 
single class (inner classes).

So a package name is org.apache.forrest.plugins.input and a class name 
is ProjectInfo (for example).

However, your argument has just as much merit. In this case I don't 
really care which way we go, as long as we are consistent. So we need at 
least one more person to express a preference and I'll be happy to go 
with whatever it is.


View raw message