[GRADLE-211] Allow shortcut notation for adressing convention properties of a plugin Created: 10/Sep/08 Updated: 04/Jan/13 Resolved: 17/Jan/12
Additionally to convention.plugins.java.someProp we should allow java.someProp.
|Comment by Jon Cox [ 23/Jan/09 ]
This seems like a good thing overall, so long as care is taken
It would be a painful if every time someone wanted to add a
Shorter is better & enhances readability... but there must be some
Obviously, whatever shortcut mechanism is used for java plugin
|Comment by Hans Dockter [ 26/Jan/09 ]
This is an important issue. It is about namespaces with regard to predictability and readabilty.
Right now you have two ways to access the propery of a plugin convention. Either convention.plugins.java.someProp or someProp. In the case of the latter, if there is a name conflict with another plugin, it is undefined which plugin wins. There have been also complaints from users about readability. For example:
sourceCompatibilty = 1.5
How do you know whether sourceCompatibilty is a local script variable or a convention property. This is hard to figure out.
So my tendency is to ditch non namespace access to covention properties and only allow java.sourceCompatibilty or the lengthy stuff above. We must make sure that plugin identifiers are unique and predictable. We should discuss this one the dev list.
|Comment by Hans Dockter [ 16/Apr/09 ]
My current opinion is that we should provide non-namespace access as well as namespaced access.
java.sourceCompatibility or sourceCompatibility
There are good use cases for both notations.
|Comment by Adam Murdoch [ 19/Apr/10 ]
We should also support closure style configuration, such as:
It might make sense to support map style configuration, too.
|Comment by Adam Murdoch [ 17/Jan/12 ]
Can we close this, now we have extensions?
|Comment by Hans Dockter [ 17/Jan/12 ]