Hmm. There's some AST trickery going on in ClasspathScriptTransformer that treats buildscript closures differently to the rest of the script. This means that the buildscript closures are applied first and the the buildscript classpath configuration is RESOLVED long before it reaches the natural point in the code to add the dependency (DefaultObjectConfigurationAction). I could dig into the ClasspathScriptTransformer to make it aware of apply as well...? It could perhaps clone the apply method statements, transform them to hit a different code path, and promote them in the script also. Seems pretty messy to me. Any suggestions for the cleanest way for me to proceed here?
On Thu, Jul 14, 2011 at 5:20 PM, Merlyn Albery-Speyer <[email protected]> wrote: > I'm going to take a look at implementing support for option 1 and 2: > > On Sat, Jul 2, 2011 at 12:53 AM, Adam Murdoch > <[email protected]> wrote: >> 1. apply group: 'mygroup', name: 'myplugin-project', version: '1.0', plugin: >> 'myplugin' >> 2. apply group: 'mygroup', plugin: 'myplugin', version: '1.0' >> 3. apply plugin: 'myplugin' >> Option 1. would resolve 'mygroup:myplugin-project:1.0' using >> buildscript.repositories, then scan the resolved artifacts (but probably not >> their dependencies) for a plugin with id 'myplugin', which it would then >> load and apply. >> Option 2. would use the plugin id as the dependency project name, and >> resolve 'mygroup:myplugin:1.0' using buildscript.repositories. >> Option 3. would work as it currently does now. That is, it scans the build >> script classpath for a plugin with id 'myplugin' > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
