Hans Dockter wrote:

On Oct 6, 2008, at 11:06 PM, Adam Murdoch wrote:



Hans Dockter wrote:
Hi Russel,

On Oct 6, 2008, at 10:44 AM, Russel Winder wrote:

With the Gradle script:

        ant.property ( file : 'build.properties' )
        type = 'jar'
        group = 'org.codehaus.gant'
        version = ant.antProject.properties.gantVersion
        usePlugin ( 'groovy' )
        dependencies {
addMavenRepo ( "file://${ System.properties.'user.home' }/.m2/repository" ) groovy ( 'org.codehaus.groovy:groovy-all:1.6-beta-2-SNAPSHOT' ) compile ( 'commons-cli:commons-cli:' + ant.antProject.properties.commonsCliVersion ) testCompile ( 'junit:junit:' + ant.antProject.properties.junitVersion )
        }
        sourceCompatibility = 1.5
        targetCompatibility = 1.5

then compilation succeeds (but the tests fail, that is another issue
though).

If however, I move the compatibility specifications above the usePlugin
specification then I get a javac invocation failure:

this is expected but unintuitive behavior. We want to introduce name spaces very soon. You then would write:

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

Then it would be clearer that you first have to introduce the namespace before you can assign something to it.


Possibly. Another approach - not necessarily incompatible with namespaces - might be to apply a project's additional properties to a plugin convention object when the convention object is added. This would also allow the convention properties to be overridden from the command-line.

Good idea.

Sidetopic: Are you in favor of namespaces for plugins?


I'm not fussed. I've found myself doing this for my own plugins, so its probably a useful thing.

As far as behaviour goes, would we change the property resolution on DefaultProject, so that for property p
1. look for property p on the project object itself
2. look for an additional property with name p
3. look for property p on each of the plugin convention objects
4. look a plugin convention object with name p (the new step)
5. look for a task with name p
6. look for a property p on the parent project

Perhaps 3 and 4 should be swapped.

Unrelated, but I wonder if there should be a step between 5 and 6 where we look for a subproject with name p?


Adam


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

   http://xircles.codehaus.org/manage_email


Reply via email to