Hey Eric,
As I understand it the same applies for any build.gradle configuration.
Every time you see
dependencies { ... }
that's shorthand for
project.dependencies { ... }
on more concretely:
project.dependencies( { ... } )
and will map directly to an API method on the Project class (which you
can find via the "DSL Reference" documentation page). From your plugin
you should be able to reach the project object as well as its root
project, subprojects, etc.
The main point of caution (not that I know plugins well enough) is to
ensure that you're configuring a project before execution actually
begins (see a chapter user manual with the word Life Cycle in the
title).
Hope that helps!
Merlyn
On Thu, 2011-02-17 at 10:21 -0800, Eric Berry wrote:
> Merlyn, Thank you. That's very cool. That will mean I do not need to
> output the build.gradle to change the source sets, but I still need to
> do so for dependencies.
>
> Is there a way to do something similar for dependencies?
>
> On Tue, Feb 15, 2011 at 7:34 PM, Merlyn Albery-Speyer
> <[email protected]> wrote:
> Hi Eric,
>
>
> You should be able to do this from within your plugin:
>
>
> project.sourceSets { main { java { srcDir myMainJavaDir }
> resources { srcDir myMainResourcesDir } } }
>
>
> That saves you the need to actually output a build.gradle file
> (and you'll already have to have one to apply your plugin in
> the first place).
>
>
> Cheers,
> Merlyn
>
>
>
> On Feb 14, 2011, at 9:54 PM, Eric Berry wrote:
>
> > Ah, I missed that one. Yeah, something like a Maven
> > Archetype would should work. My plugin uses a really simple
> > builder which let's me define directory structures and file
> > templates.
> >
> > Eg
> > [code]
> > new DSB().src {
> > main {
> > java {
> > // uses GStringTemplateEngine to render the
> > template
> > "${project.name}.java" template:
> > "plugin.java.template", classname: "${project.name}"
> > }
> > resources {
> > "${project.name}.props" content:
> > "plugin.${project.name}.name=${project.name}"
> > }
> > }
> > }
> > [/code]
> >
> > For now, I think I can get away with this if it's possible
> > to programmatically add dependencies on the fly. I've been
> > looking around the documentation, but I don't see anything
> > that looks like it'll help there. Any ideas here?
> >
> > On Mon, Feb 14, 2011 at 4:58 PM, Merlyn Albery-Speyer
> > <[email protected]> wrote:
> > I've had some success generating build.gradle files
> > containing the dependencies and exclusions from a
> > pom.xml file - pretty much just using an XmlSlurper.
> > I'm not sure I appreciate what you're asking about,
> > however GRADLE-197 does not appear to be related. It
> > sounds like you're looking for something like the
> > maven archetype, which was a recent
> > gradle-user/gradle-dev topic. Or it is purely the
> > build.gant that you're looking to create?
> >
> >
> >
> > On Feb 14, 2011, at 4:25 PM, Eric Berry wrote:
> >
> > > Has anyone had any luck with Gradle build file
> > > generation?
> > >
> > > I'm creating a plugin to help jEdit plugin
> > > developers get started. The plugin thus far will
> > > allow users to run 'gradle init' in their
> > > directory, and it'll create the base directory
> > > structure. I'd like to be able to safely add
> > > things to the build file after commands are run.
> > > For example, in the 'init' task I'd like to ask
> > > the user if their plugin is intended for jEdit
> > > 4.3, jEdit 4.4, or jEdit 4.5. Based on their
> > > choice, I'd want to add the appropriate dependency
> > > to the build.gradle file.
> > >
> > > I suppose this is one benefit to being able to use
> > > XML, java processes can manipulate the XML
> > > structure pretty easily without worrying about
> > > closing braces in the wrong places.
> > >
> > > I saw this ticket:
> > > http://jira.codehaus.org/browse/GRADLE-197
> > >
> > > Is it a best bet to wait for something to come out
> > > of it, or is there a work-a-round I can use for
> > > this?
> > >
> > > Thanks for any help.
> > > Eric Berry
> > >
> > > --
> > > Learn from the past. Live in the present. Plan for
> > > the future.
> > > Blog:
> > > http://www.townsfolkdesigns.com/blogs/elberry
> > > jEdit <http://www.jedit.org> - Programmer's Text
> > > Editor
> > > Bazaar <http://bazaar.canonical.com> - Adaptive
> > > Version Control System
> >
> >
> >
> >
> >
> > --
> > Learn from the past. Live in the present. Plan for the
> > future.
> > Blog: http://www.townsfolkdesigns.com/blogs/elberry
> > jEdit <http://www.jedit.org> - Programmer's Text Editor
> > Bazaar <http://bazaar.canonical.com> - Adaptive Version
> > Control System
>
>
>
>
>
> --
> Learn from the past. Live in the present. Plan for the future.
> Blog: http://www.townsfolkdesigns.com/blogs/elberry
> jEdit <http://www.jedit.org> - Programmer's Text Editor
> Bazaar <http://bazaar.canonical.com> - Adaptive Version Control System
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
