What I was envisioning was possibly also a more generic initProject task that 
basically looks at all of the sourceSets for an existing project and simply 
generates the missing directory structures (which would pick up custom 
adjustments to directories).

This generic "create directory structures from existing sourceSets" behavior 
was what I was trying to convey, as the other create/init tasks have 
create/modify build.gradle file functions followed by a create directory 
structures operation.

An initProject task (or possibly a project method) similar to what I've 
described seems like something that could easily be folded into gradle core, 
and then leveraged by the more specific createJavaProject and initJavaProject 
tasks that you have so usefully implemented.

I could also readily see in the future a createXyzProject type rule that 
queries the xyz plugin (or some alternative project type delegate object) as to 
what really needs to be inserted into a build.grade file for it to properly 
function.

What you have right now is extremely useful -- everything else I've mentioned 
is just thinking out loud :-)

-Spencer

--- On Wed, 4/20/11, Eric Berry <[email protected]> wrote:

From: Eric Berry <[email protected]>
Subject: Re: [gradle-user] ANN: A gradle templates plugin.
To: [email protected]
Date: Wednesday, April 20, 2011, 12:15 PM

There are a few tasks that come with the plugin. The create*Project tasks 
actually do most of what you say. They prompt the user for a new project name, 
create a directory for that project, and then layout the default directory 
structure. They also spit out a templated build.gradle file that's specific for 
each type.


Eg. The createJavaProject creates a build.gradle file with just "apply plugin: 
'java'" in it. The createGroovyProject applies the groovy plugin, but also puts 
the base "dependencies { groovy localGroovy() }" into the build.gradle file as 
well. createWebappProject additionally asks the user if they want to use the 
Jetty plugin, and based on that decision appends that plugin to the 
build.gradle file.


The init*Project tasks will prepend the appropriate plugin to the existing 
build.gradle file and setup any missing directories, but they are intended to 
be used inside a pre-existing project.

The create*Class tasks are intended to only work in an existing project and 
need to know what the main.groovy or main.java directories are. In the future 
these tasks could probably use the test sourceSets as well to generate unit 
tests for the newly created Class.


Although, I think that the create*Project and init*Project tasks should work 
with the perspective default sourceSets. I'll apply the appropriate plugin, and 
then use the default sourceSets to generate the base directory structure.


Thanks.
Eric

On Wed, Apr 20, 2011 at 4:54 AM, Spencer Allain <[email protected]> 
wrote:

--- On Wed, 4/20/11, Eric Berry <[email protected]> wrote:

I actually didn't need to even do that. I can just test for 
'project.sourceSets?.main?.java?.srcDirs'. If it's available I use it, 
otherwise I throw an exception stating that it looks like the Java plugin is 
not installed, and so I cannot determine the main Java source directory.

This should work for a pre-existing project (one defined via settings.gradle 
and/or build.gradle files), but if it is also intended to help setup a new 
project from scratch there likely wouldn't be a project specification other 
than maybe just the name anywhere.


Building from scratch ideally would attempt to either directly query the 
JavaBasePlugin or potentially
 do something even more radical such as spitting out a templated build.gradle 
file that would apply plugin: 'java' and/or apply plugin: 'groovy', etc. then 
use the aforementioned logic to create the directory structures.


Actually, instead of looking for a specifically named sourceSet, it might make 
sense to simply find all project.sourceSets that have defined "srcDirs" (guess 
that'd be a convention) and try to create the directory structures they 
require.  That way you wouldn't really have to know or care which plugins were 
being applied at the directory creation phase, and simply attempt to create 
missing directories for sourceSets that are defined.


-Spencer





-- 
Learn from the past. Live in the present. Plan for the future.
Blog: http://eric-berry.blogspot.com

jEdit <http://www.jedit.org> - Programmer's Text Editor
Bazaar <http://bazaar.canonical.com> - Version Control for Humans


Reply via email to