name space.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

name space.

Stefan Groschupf
Hi Gradle developers,
the underlaying technologie is great - thanks for all the effort,  
though I think the usability and ease of understand build scripts  
could be better.
Therefore I would love to make some suggestions.

Namespace.
It is very confusing to me when reading other gradle files what is a  
user defined variable and what is a variable defined by gradle.
I think it would make a lot of sense to have as less as possible key  
words or gradle defined variables. Therefore I suggest to ''prefix" in  
a oo style all gradle defined variables.

So instead of having:
group = 'net.sf.katta'
version = '1.0-SNAPSHOT'
...

I would prefer something like:
project.version = '1.1'
project.group = 'net.sf.katta'

This would give readers more context and naturally better to understand.

Also instead of
usePlugin('java')
sourceCompatibility = 1.5
targetCompatibility = 1.5

I think it would be much better to understand to this kind of syntax:
usePlugin('java')
java.sourceCompatibility = 1.5
java. targetCompatibility = 1.5

That would be a great general pattern for plugins. Adding the plugin  
by usePlugin('myPlugin') and than just configuring it by defining  
properties by myPlugin.propertyName = value. I think this is much  
easier and more natural to understand for an developer.

Look how beautiful a build script could look like: :-D


project.version = '1.1'
project.group = 'net.sf.katta'

usePlugin('java')
java.sourceCompatibility = 1.5
java. targetCompatibility = 1.5


usePlugin('myPlugin')
myPlugin.propertyName = value

Stefan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: name space.

hans_d
Administrator
Hi Stefan,

On Sep 10, 2008, at 8:13 AM, Stefan Groschupf wrote:

> Hi Gradle developers,
> the underlaying technologie is great - thanks for all the effort,  
> though I think the usability and ease of understand build scripts  
> could be better.
> Therefore I would love to make some suggestions.
>
> Namespace.
> It is very confusing to me when reading other gradle files what is  
> a user defined variable and what is a variable defined by gradle.
> I think it would make a lot of sense to have as less as possible  
> key words or gradle defined variables. Therefore I suggest to  
> ''prefix" in a oo style all gradle defined variables.
>
> So instead of having:
> group = 'net.sf.katta'
> version = '1.0-SNAPSHOT'
> ...
>
> I would prefer something like:
> project.version = '1.1'
> project.group = 'net.sf.katta'

This notation is already possible. But is does not do what you want.  
Our build script is associated with a project object and delegates to  
it.

version = '1.1' is equivalent to project.version = '1.1'

But this puts the property in the same bucket as:

myVersion = '1.2' (which is a custom property introduced by the build  
script).

We have to think about to which bucket version and group belongs to.  
Are they general project properties or do they belong to the  
dependency manager, or to the Java plugin? http://jira.codehaus.org/ 
browse/GRADLE-212

We have to think about how to separate build-in project properties  
from custom properties. http://jira.codehaus.org/browse/GRADLE-213

>
> This would give readers more context and naturally better to  
> understand.
>
> Also instead of
> usePlugin('java')
> sourceCompatibility = 1.5
> targetCompatibility = 1.5
>
> I think it would be much better to understand to this kind of syntax:
> usePlugin('java')
> java.sourceCompatibility = 1.5
> java. targetCompatibility = 1.5
>

Internally we use already different buckets for the convention  
properties of plugins. So right now you can already write:

usePlugin('java')
convention.plugins.java.sourceCompatibility = 1.5

Obviously this is not that convenient and I think you shortcut  
proposal is a good idea which is very easy to implement. You might  
follow the issue under: http://jira.codehaus.org/browse/GRADLE-211

In general we might think about whether we should continue to allow  
to access all different kind of properties without specifying there  
namespace.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email