2009/2/4 Richard Walker <[email protected]>
>
>
> When I had a quick go at making the 'create' task yesterday, I used the
> plugin variables to provide the skeleton structure for me:
>
> Java Plugin: srcDirs, resourceDirs, testSrcDirs, testResourceDirs
> Groovy Plugin: groovySrcDirs, groovyTestSrcDirs
>
> - These could easily be redefined in build.gradle before calling the create
> task.
>
> But what I was after by using the command line was to be able to also
> create
> a skeleton build.gradle file. I would find it easier to have the file
> (build.gradle) created and have to amend/add to it rather than create it
> from scratch each time I started a new project (IMHO).
>
> Admittedly I need to spend some time looking at the current Gradle source
> to
> see what approach would be a best fit. Nothing to say both approaches
> couldn't work:
>
> 1) If there are command line variables and no build.gradle do one
> approach
> 2) If build.gradle does exist use the defaults defined in that.
>
Totally agree that both could/should be possible.
I was thinking this way because in the current plugin system, plugins do not
have to map to project types (some do like the JavaPlugin) and multiple
plugins can be used at the same time e.g: JavaPlugin + OsgiPlugin. So
because plugins can be used together we could make it so that you could do:
gradle init ([list of plugins])? projectName
gradle init java osgi :com.test:BasicProject
assumptions here are: executed in directory that is going to contain a
subdirectory called BasicProject, all directories are created based on the
defaults of the java plugin, a build.gradle file is created containing:
usePlugin('java')
usePlugin('osgi')
version=0.1
This would be the absolute basic gradle.build file that would adhere to the
requested project. We probably should add some usefull things that you can
do with the enabled plugins into the generated build.gradle file that you
are probably going to need:
// always
dependencies {
// compile
// testCompile
}
// when using the OSGI plugin
configure('archive_jar.osgi') {
// examples instructions for the OSGI MANIFEST headers
}
Additionally we could allow specifing your default project
compile/testCompile/runtime/ ... dependencies (absolute defaults/ per
plugin) , repo to use somewhere and add them when you do a gradle init. (I
would love this :), tired of always adding commons, joda-time, slf4j,
logback, ...)
Ok by writing this I've actually already provided another way to define a
project layout, just need to broden what I suggested for defining default
dependencies and also allow setting the default values used for e.g. by the
JavaPlugin. That would become java:mySettings for example in the gradle init
command => gradle init java:myStructure :com.test:BasicProject.
And when the build.gradle file exists we use it and run init with the
build.gradle file as source for the defaults.
So we end up with 3 possibilities:
- plugin defaults
- plugin uses values from a some template like thing
- plugin uses values from a build.gradle file
Hope you like these ideas, comments are always welcome.
>
> R.
>
> Tom Eyckmans wrote:
> >
> > I think it would be interesting to have something like the archetypes but
> > to
> > prevent Gradle from forcing a certain structure on users, we might add a
> > Gradle twist to it.
> > Lets say you want to start a new project you create the build.gradle file
> > with just the basics e.g:
> >
> > usePlugin('java')
> >
> > + where you want the source / test dirs / libs ... to be, if they are not
> > specified the defaults are used and you have the effect of an archetype
> > without the extras
> > + libraries that you are going to need
> >
> > then you run gradle init or something like it and dirs are
> > created/libraries
> > downloaded/ ... depending on the plugins there can be additional
> artifacts
> > that are created thinking of project files.
> >
> > This way we don't force the structure and don't require users to know
> > additional command line stuff.
> >
> > 2009/2/4 Richard Walker <[email protected]>
> >
> >>
> >>
> >> This is what I was hoping to get away from.
> >>
> >> At the first hurdle having to manually create the directories and files
> >> or
> >> having to drop into Maven to get started puts me off.
> >>
> >> I think it would be a real seller if I could create all the files and
> >> directories I needed (including the skeleton gradle.build) from just a
> >> command (or two).
> >>
> >> I only used Maven as an example but I was mindful other projects have
> the
> >> facility to take care of many of these manual tasks (e.g. Grails and
> >> scaffolding).
> >>
> >> After all the gradle motto is:
> >> impossible possible, the possible easy, and the easy elegant.
> >>
> >> Regards, Richard.
> >>
> >> Ps. I'd be quite happy to write some of this myself - just want to know
> >> if
> >> it's something that people would go for.
> >>
> >>
> >> Raphaël wrote:
> >> >
> >> > The maven archetype plugin could help you there.
> >> >
> >> > It is language agnostic, the only thing needed is a pom.xml (which
> >> could
> >> > be
> >> > minimal if you use graddle)
> >> >
> >> > What you have to do is just to create a archetype.
> >> >
> >> > Regards,
> >> >
> >> > Raphaël
> >> >
> >> > 2009/2/4 Richard Walker <[email protected]>
> >> >
> >> >>
> >> >> Are there any archetype-like features in gradle that will allow me to
> >> >> quickly
> >> >> create a project, it's folders and basic dependencies with a command
> >> >> similar
> >> >> to that I'd find in Maven 2?
> >> >>
> >> >> eg. gradle -DgroupId=test.com -DprojectName=BasicProject
> >> >> -Dproject.type=groovy create
> >> >>
> >> >> Would there be any interest in creating such a feature?
> >> >>
> >> >> Cheers, Richard.
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/Gradle-Archetypes--tp21826454p21826454.html
> >> >> Sent from the gradle-user mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe from this list, please visit:
> >> >>
> >> >> http://xircles.codehaus.org/manage_email
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Gradle-Archetypes--tp21826454p21828622.html
> >> Sent from the gradle-user mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Gradle-Archetypes--tp21826454p21831735.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
