On 25/10/2010, at 2:10 AM, Dan Tanner wrote: > I'm curious of the differences between a compiled jar of custom tasks, > and using "apply from" for shared configuration/tasks. I'm just using > apply from, pointing to a build.gradle file I stuff in our internal > maven repo...I'm wondering when I'd choose one technique over the > other.?
Some differences: 1. A jar can contribute classes to the applying build script's classpath. A script cannot. For example, the jar might contain a custom task implementation which the build script can use. Similarly, the jar might contain plugin implementations which the build script can apply. 2. The jar can package up resources which its classes can use. 3. The jar can define ids for the plugins it contains. 4. The syntax for applying a jar and a script are different. There's less boiler plate required to apply a script plugin. 5. You implement a script using the Gradle DSL. You cannot use the Gradle DSL when implementing the classes in a jar. But, conversely, you can use any JVM language to implement the classes in a jar. 6. A jar requires a separate project to build and deploy it. A script does not, but certainly can (for example if you want to write tests for it or automate its publication or generate documentation for it, or whatever). So, at the moment, a script is a light-weight but less capable way to modularise your build logic, and a jar is a heavier-weight but more capable way. Most of these differences really just reflect history, rather than where we want to end up. Applying scripts is a relatively new feature in Gradle. Over time, we will smooth out the differences between the two. Some things we want to achieve: * Use the same DSL syntax to apply either a script or a jar plugin. * Allow you to apply a jar plugin or script using the Gradle dependency notation, rather than just by id or uri. * Allow you to apply a jar plugin by uri, as you can for scripts. The uri will be able to point to either a precompiled jar or to the source for the jar and Gradle will take care of building it (as it does for the buildSrc project). * Allow a script to contribute classes to the build script's classpath. * Allow you to use the Gradle DSL to implement a jar plugin. That is, there will be pretty much no difference between the two: You can point to the source or the compiled artifact. You can publish the source or the compiled artifact to a repository, or refer to them by uri. You can use a single source file or multiple source files. You can contribute classes to the build script. You can use any mix of the Gradle DSL or any other JVM language to implement the build logic. > > On Fri, Oct 22, 2010 at 9:39 AM, Etienne Studer > <[email protected]> wrote: >> Thanks Rene for your confirmation that buildscript{} is the proper way. >> >> Regards, Etienne >> >> >> On 22.10.2010, at 13:24, Rene Groeschke wrote: >> >>> Hi Etienne, >>> yes, to have custom jars available in the gradle classpath you have to add >>> them as a dependency with the buildscript closure. As an example you can >>> have a look at this sample build file at >>> >>> http://github.com/breskeby/gradleplugins/blob/0.9-upgrade/pdePlugin/src/samples/productpluginsbuild/ProductOnPluginsExample/build.gradle >>> >>> regards, >>> René >>> >>> Am Fr, 22.10.2010, 09:55, schrieb Etienne Studer: >>>> Hi >>>> >>>> >>>> If I have a jar file with a set of compiled Gradle tasks, how can I make >>>> them available in a Gradle project? I could not find the answer in the >>>> documentation. >>>> >>>> Should I use the buildscript {} method and add my jar file with the >>>> custom Gradle tasks as a dependency? >>>> >>>> Regards, Etienne >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> Etienne Studer >> Senior Software Developer >> >> Canoo Engineering AG >> Kirschgartenstrasse 5 >> CH-4051 Basel >> >> T +41 61 228 94 44 >> F +41 61 228 94 49 >> >> [email protected] >> www.canoo.com >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
