GRADLE_WRAPPER_ALWAYS_DOWNLOAD |
- If set totrue, the distribution directory and the distribution zip gets always
+ | If set to true, the distribution directory and the distribution zip gets always
deleted when
gradlew
is run and the distribution zip is freshly downloaded.
Index: trunk/src/docs/userguide/multiproject.tex
===================================================================
--- trunk/src/docs/userguide/multiproject.tex (revision 1213)
+++ trunk/src/docs/userguide/multiproject.tex (working copy)
@@ -2,7 +2,7 @@
\chapter{Multi-project builds} % (fold)
\label{cha:multi_project_builds}
-The powerful support for multi-project builds is one of Gradles unique selling points. This topic is also the intellectually most challenging.
+The powerful support for multi-project builds is one of Gradle's unique selling points. This topic is also the intellectually most challenging.
\section{Cross Project Configuration} % (fold)
\label{sec:cross_project_configuration}
Let's start with a very simple multi-project build. After all Gradle is a general purpose build tool at its core. So the projects don't have to be java projects. Our first examples are about marine life.
@@ -158,7 +158,7 @@
\label{sec:execution_rules_for_multi_project_builds}
When we have executed the \texttt{hello} task from the root project dir things behaved in an intuitive way. All the \texttt{hello} tasks of the different projects were executed. Let's switch to the \texttt{bluewhale} dir and see what happens if we execute Gradle from there.
\outputInputGradle[current dir: userguide/multiproject/partialTasks/water/bluewhale]{../../samples/userguideOutput/multiprojectSubBuild.out}
-The basic rule behind Gradles behavior is simple. Gradle looks down the hierarchy, starting with the \emph{current dir}, for tasks with the name \texttt{hello} an executes them. One thing is very important to note. Gradle \emph{always} evaluates \emph{every} project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradles \emph{Cross Project Configuration} \emph{every} project has to be evaluated before \emph{any} task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to \texttt{bluewhale} and \texttt{krill}.
+The basic rule behind Gradle's behavior is simple. Gradle looks down the hierarchy, starting with the \emph{current dir}, for tasks with the name \texttt{hello} an executes them. One thing is very important to note. Gradle \emph{always} evaluates \emph{every} project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradle's \emph{Cross Project Configuration} \emph{every} project has to be evaluated before \emph{any} task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to \texttt{bluewhale} and \texttt{krill}.
\codeGradleFile[bluewhale - ]{../../samples/userguide/multiproject/partialTasks/water/bluewhale/build.gradle}
\codeGradleFile[krill - ]{../../samples/userguide/multiproject/partialTasks/water/krill/build.gradle}
\outputInputGradle[userguide/multiproject/partialTasks/water]{../../samples/userguideOutput/multiprojectPartialTasks.out}
@@ -286,7 +286,7 @@
\subsection{Real Life examples} % (fold)
\label{sub:real_life_examples}
-Gradles multi-project features are driven by real life use cases. The first example for describing such a use case, consists of two webapplication projects and a parent project that creates a distribution out of them.\footnote{The real use case we had, was using \url{http://lucene.apache.org/solr}, where you need a separate war for each index your are accessing. That was one reason why we have created a distribution of webapps. The Resin servlet container allows us, to let such a distribution point to a base installation of the servlet container.} For the example we use only one build script and do \emph{cross project configuration}.
+Gradle's multi-project features are driven by real life use cases. The first example for describing such a use case, consists of two webapplication projects and a parent project that creates a distribution out of them.\footnote{The real use case we had, was using \url{http://lucene.apache.org/solr}, where you need a separate war for each index your are accessing. That was one reason why we have created a distribution of webapps. The Resin servlet container allows us, to let such a distribution point to a base installation of the servlet container.} For the example we use only one build script and do \emph{cross project configuration}.
\begin{Verbatim}[frame=single,label=Project Tree]
D- webDist
F- settings.gradle
@@ -341,7 +341,7 @@
\label{sec:property_and_method_inheritance}
Properties and methods declared in a project are inherited to all its subprojects. This is an alternative to configuration injection. But we think that the model of inheritance does not reflect the problem space of multi-project builds very well. In a future edition of this userguide we might write more about this.
-Method inheritance might be interesting to use as Gradles \emph{Configuration Injection} does not support methods yet (but will in a future release.).
+Method inheritance might be interesting to use as Gradle's \emph{Configuration Injection} does not support methods yet (but will in a future release.).
You might be wondering why we have implemented a feature we obviously don't like that much. One reason is that it is offered by other tools and we want to have the check mark in a feature comparison :). And we like to offer our users a choice.
% section property_and_method_inheritance (end)
Index: trunk/src/docs/userguide/maven.tex
===================================================================
--- trunk/src/docs/userguide/maven.tex (revision 1213)
+++ trunk/src/docs/userguide/maven.tex (working copy)
@@ -3,7 +3,7 @@
\label{cha:interacting_with_maven_repositories}
\section{Introduction} % (fold)
\label{sec:introduction}
-With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradles deployment is 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
+With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradle's deployment is 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
Deploying to a Maven repository is only half the fun if you don't have a pom. Fortunately Gradle can generate this pom for your, from the dependency information it has.
% section introduction (end)
@@ -20,7 +20,7 @@
\end{Verbatim}
That is all. Calling the \texttt{uploadLibs} task will generate the pom and deploys the artifact and the pom to the specified repository.
-There is some more work to do, if you need support for other protocols than \texttt{file}. In this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the protocol you need. The available protocols and the corresponding libraries are listed in table \ref{wagonLibs}. Those libraries have again transitive dependencies which have transitive dependencies. You need to provide the complete list of those to the MavenDeployer{\footnote{It is planned for a future release to provide out-of-the-box support for this}}. The easiest way to do this is the following:
+There is some more work to do if you need support for protocols other than \texttt{file}. In this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the protocol you need. The available protocols and the corresponding libraries are listed in table \ref{wagonLibs}. Those libraries have again transitive dependencies which have transitive dependencies. You need to provide the complete list of those to the MavenDeployer{\footnote{It is planned for a future release to provide out-of-the-box support for this}}. The easiest way to do this is the following:
\begin{Verbatim}
dependencies {
addConfiguration('deployerJars')
@@ -156,7 +156,7 @@
\item A dependency belongs to only one configuration: The first thing Gradle checks is whether there is a mapping for this configuration. If there is none, the dependency is by default not added to the pom. By setting the mapping property \texttt{includeUnmappedConfigurations} to true, such a dependency will be added. If the configuration is mapped, the corresponding scope is obvious and the dependency is added.
\item A dependency belongs to more than one mapped configuration: If the mapped configurations map to the same scope the situation is clear. If the mapped configurations map to different scopes the configuration mapping with the highest priority is chosen. If there is more than one configuration with a highest priority and they map to different scopes an exception is thrown.
\end{itemize}
-Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in the Gradle exlude rule the organisation as well as the module name is specified (as Maven needs both in contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom.
+Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in the Gradle exclude rule the organisation as well as the module name is specified (as Maven needs both in contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom.
\subsection{Planned future features} % (fold)
\label{sub:planned_future_features}
Index: trunk/src/docs/userguide/maven.xml
===================================================================
--- trunk/src/docs/userguide/maven.xml (revision 1213)
+++ trunk/src/docs/userguide/maven.xml (working copy)
@@ -3,7 +3,7 @@
Introduction
With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This
- includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradles deployment is
+ includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradle's deployment is
100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
Deploying to a Maven repository is only half the fun if you don't have a pom. Fortunately Gradle can
@@ -26,7 +26,7 @@
uploadLibs
task will generate the pom and deploys the artifact and the pom to the specified repository.
- There is some more work to do, if you need support for other protocols thanfile. In
+ There is some more work to do if you need support for protocols other than file. In
this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the
protocol you need. The available protocols and the corresponding libraries are listed in . Those libraries have again transitive dependencies which have transitive
@@ -201,7 +201,7 @@
task. This install task depends on the
libs
task of the Java plugin. It installs your libraries to your local Maven repository. If the default
- location for the local repository is redefined in a Mavensettings.xml, this is
+ location for the local repository is redefined in a Maven settings.xml, this is
considered by this task.
@@ -309,7 +309,7 @@
Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in
- the Gradle exlude rule the organisation as well as the module name is specified (as Maven needs both in
+ the Gradle exclude rule the organisation as well as the module name is specified (as Maven needs both in
contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom.
Index: trunk/src/docs/userguide/javaPlugin.xml
===================================================================
--- trunk/src/docs/userguide/javaPlugin.xml (revision 1213)
+++ trunk/src/docs/userguide/javaPlugin.xml (working copy)
@@ -10,7 +10,7 @@
The
buildDir
- property is a property of the project object. It defaults tobuild.
+ property is a property of the project object. It defaults to build.
Gradle's conventions contain a convention for the directory hierarchy as well as conventions for the element
@@ -16,7 +16,7 @@
Gradle's conventions contain a convention for the directory hierarchy as well as conventions for the element
names of the hierarchy. For example the
srcDirs
- are relative to thesrcRoot. Therefore
+ are relative to the srcRoot. Therefore
srcDirs
is a read-only property. If you want to change the name of the source dirs you need to do this via the
srcDirNames
@@ -22,11 +22,11 @@
srcDirNames
property. But the paths you specify here are
relative
- to thesrcRoot. This has the advantage to make bulk changes easy. If you change
+ to the srcRoot. This has the advantage to make bulk changes easy. If you change
srcRoot
from
src
- tosource, this automatically applies to all directory properties which are relative to
+ to source, this automatically applies to all directory properties which are relative to
srcRoot. As this also introduces an inflexibility, we have additional floating dirs, which
are not bound to any hierarchy (see ). For example code
generation tool could make use of this, by adding a source dir which is located in the build folder.
@@ -367,7 +367,7 @@
clean
and
javadoc
- which does not depends oninit).
+ which does not depends on init).
@@ -406,7 +406,7 @@
property. This property is mapped to the
buildDir
property of the project. In future releases there will be more control of what gets deleted. If you need
- more control now, you can use theAnt delete task.
+ more control now, you can use the Ant delete task.
@@ -415,7 +415,7 @@
Resources
task has two instances,
resources
- andtestResources.
+ and testResources.
Java Convention Object - Resource Properties
@@ -463,7 +463,7 @@
Compile
task has two instances,
compile
- andtestCompile.
+ and testCompile.
Java Convention Object - Compile Properties
@@ -588,7 +588,7 @@
.class
files. The default include is
**/*Tests.class", "**/*Test.class
- and the default exclude is**/Abstract*.class.
+ and the default exclude is **/Abstract*.class.
The test task delegates to Ants junit task. TestNG is not supported yet. You can expect TestNG support in
one of our next releases.
@@ -600,7 +600,7 @@
Bundle
task has two instances,
libs
- anddists. The Bundle task is a special animal. It is a container for archive tasks (jar,
+ and dists. The Bundle task is a special animal. It is a container for archive tasks (jar,
zip, ...).
@@ -643,7 +643,7 @@
libs
task. The task name is by default
archive_jar
- and can of course be manipulated by this name. This jar contains the content of the
+ and can of course be manipulated by this name. This jar contains the content of the
classesDir. This is the behavior your are used from Maven. If you are happy with that you
usually don't have to touch this task. Except if you want to change the names of the generated archives.
@@ -694,7 +694,7 @@
- This adds an archive task with the namearchive_zip. It is important to distinguish
+ This adds an archive task with the name archive_zip. It is important to distinguish
between the name of the archive task and the name of the archive generated by the archive task. The name
of the generated archive file is by default the name of the project. The default for naming generated
archives can be changed with the
@@ -833,7 +833,7 @@
Common Properties
- The name of the generated archive is assembled from the task propertiesbaseName,
+ The name of the generated archive is assembled from the task properties baseName,
classifier
and
extension
@@ -910,7 +910,7 @@
Merging
If you want to merge the content of other archives into the archive to be generated Gradle offers you
- two methods. One ismerge:
+ two methods. One is merge:
Under the hood Gradle scans the extension of the archives to be merged. According to the extension, it
creates a
ZipFileSet
- orTarFileSet. The closure is applied to this newly created file container. \\ There
- is another method for merging calledmergeGroup.
+ or TarFileSet. The closure is applied to this newly created file container. \\ There
+ is another method for merging called mergeGroup.
Manifest
The convention object of the JavaPlugin has a
manifest
- property pointing to an instance of
org.gradle.api.bundling.GradleManifest. With this
GradleManifest
@@ -996,7 +996,7 @@
Upload
task has two instances,
uploadLibs
- anduploadDists. An easy way of describing there behavior, is that all archives added to
+ and uploadDists. An easy way of describing there behavior, is that all archives added to
the
libs
and
@@ -1018,7 +1018,7 @@
org.gradle.api.tasks.ide.eclipse.EclipseClasspath
- has a default instance with the nameeclipseCp. It generates a
+ has a default instance with the name eclipseCp. It generates a
.classpath
file.
@@ -1061,7 +1061,7 @@
org.gradle.api.tasks.ide.eclipse.EclipseProject
- has a default instance with the nameeclipseProject. It generates a
+ has a default instance with the name eclipseProject. It generates a
.project
file.
Index: trunk/src/docs/userguide/commandLine.xml
===================================================================
--- trunk/src/docs/userguide/commandLine.xml (revision 1213)
+++ trunk/src/docs/userguide/commandLine.xml (working copy)
@@ -131,6 +131,6 @@
- The same information is printed to the console when you executegradle -h.
+ The same information is printed to the console when you execute gradle -h.
Index: trunk/src/docs/userguide/buildscripts.xml
===================================================================
--- trunk/src/docs/userguide/buildscripts.xml (revision 1213)
+++ trunk/src/docs/userguide/buildscripts.xml (working copy)
@@ -10,7 +10,7 @@
Hello World
In Gradle everything revolves around tasks. The tasks for your build are defined in the build script. To
- try this out, create the following build script namedbuild.gradle.
+ try this out, create the following build script named build.gradle.
Enter with your shell into the containing directory and execute the build script
@@ -36,7 +36,7 @@
terminology to Ant as we think the word 'task' is more expressive than the word 'target'. Unfortunately this
introduces a terminology clash with Ant, as Ant calls its commands, like
javac
- orcopy, task. So if we talk about tasks, we
+ or copy, task. So if we talk about tasks, we
always
mean Gradle tasks, which are the equivalent to Ant's targets. If we talk about Ant tasks (Ant commands), we
explicitly say
@@ -46,7 +46,7 @@
Build scripts are code
- Gradles build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
+ Gradle's build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
@@ -86,7 +86,7 @@
Manipulating existing tasks
- Once tasks are created they can be accessed via anAPI. This is different to Ant. For
+ Once tasks are created they can be accessed via an API. This is different to Ant. For
example you can create additional dependencies.
Ant
- Let's talk a little bit about Gradles Ant integration. Ant can be divided into two layers. The first layer
+ Let's talk a little bit about Gradle's Ant integration. Ant can be divided into two layers. The first layer
is the Ant language. It contains the syntax for the build.xml, the handling of the targets, special
constructs like macrodefs, etc. Basically everything except the Ant tasks and types. Gradle does not offer
any special integration for this first layer. Of course you can in your build script execute an Ant build as
@@ -143,10 +143,10 @@
.
- The second layer of Ant is its wealth of Ant tasks and types, likejavac,
+ The second layer of Ant is its wealth of Ant tasks and types, like javac,
copy
- orjar. For this layer Gradle provides excellent integration simply by relying on Groovy.
- Groovy is shipped with the fantasticAntBuilder. Using Ant tasks from Gradle is as
+ or jar. For this layer Gradle provides excellent integration simply by relying on Groovy.
+ Groovy is shipped with the fantastic AntBuilder. Using Ant tasks from Gradle is as
convenient and more powerful than using Ant tasks from a
build.xml
file. Let's look at an example:
@@ -196,7 +196,7 @@
- This is equivalent to runninggradle clean run. In a multi-project build every
+ This is equivalent to running gradle clean run. In a multi-project build every
subproject can have its own specific default tasks. If a subproject does not specify default tasks, the
default tasks of the parent project are used (if defined).
Index: trunk/src/docs/userguide/ideSupport.tex
===================================================================
--- trunk/src/docs/userguide/ideSupport.tex (revision 1213)
+++ trunk/src/docs/userguide/ideSupport.tex (working copy)
@@ -3,9 +3,9 @@
\label{cha:ide_support}
\section{IntelliJ} % (fold)
\label{sec:intellij}
-Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradles build script\footnote{Gradle is build with Gradle} has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be interpreted as a Groovy script. In the case of Gradle you can define such a pattern for \emph{build.gradle} and \emph{settings.gradle}. This will already help very much. What is missing is the classpath to the Gradle binaries to offer content assistance for the Gradle classes. You might add the gradle jar (which you can find in your distribution) to your project's classpath. It does not really belong there, but if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use additional libraries for your build scripts they would further pollute your project classpath.
+Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradle's build script\footnote{Gradle is build with Gradle} has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be interpreted as a Groovy script. In the case of Gradle you can define such a pattern for \emph{build.gradle} and \emph{settings.gradle}. This will already help very much. What is missing is the classpath to the Gradle binaries to offer content assistance for the Gradle classes. You might add the gradle jar (which you can find in your distribution) to your project's classpath. It does not really belong there, but if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use additional libraries for your build scripts they would further pollute your project classpath.
-We hope that in the future \texttt{build.gradles} get special treatment by IntelliJ and you will be able to define a specific classpath for them.
+We hope that in the future \texttt{build.Gradle's} get special treatment by IntelliJ and you will be able to define a specific classpath for them.
% section intellij (end)
\section{Eclipse} % (fold)
Index: trunk/src/docs/userguide/logging.xml
===================================================================
--- trunk/src/docs/userguide/logging.xml (revision 1213)
+++ trunk/src/docs/userguide/logging.xml (working copy)
@@ -4,7 +4,7 @@
by this. On the other hand you need the relevant information for figuring out if things have gone wrong. Gradle
has added to log-levels to the ones normally used. Those levels are
QUIET
- andLIFECYCLE. The latter is the default and is telling you just what task is getting
+ and LIFECYCLE. The latter is the default and is telling you just what task is getting
executed or skipped.
@@ -14,7 +14,7 @@
WARN
and
ERROR
- levels are included in all the other levels, exceptQUIET, where only
+ levels are included in all the other levels, except QUIET, where only
ERROR
is included. In you find the command line switches for stacktrace
logging.
@@ -106,9 +106,9 @@
ERROR
level. This behavior is configurable. Gradle provides a couple of switches for this. To change the log
level, standard out is redirected to, when your build script gets evaluated, the project object offers a
- method called
+ method called
Project#captureStandardOutput. To change the log level for standard out during task execution,
- tasks offer a method also with the nameTask#captureStandardOutput.
Tasks and projects also offer a method
disableStandardOutputCapture
@@ -128,7 +128,7 @@
treats them as log levels. In a future version of Gradle we want to provide a logger which provides
additional log methods
quiet
- andlifecycle.
+ and lifecycle.
You can also hook into Gradle's logging system from within other classes (classes from the buildSrc
directory for example). Simply use a slf4j logger.
Index: trunk/src/docs/userguide/tasks.tex
===================================================================
--- trunk/src/docs/userguide/tasks.tex (revision 1213)
+++ trunk/src/docs/userguide/tasks.tex (working copy)
@@ -24,7 +24,7 @@
resources.from(file('resources')).to(file('target')).
includes('**/*.txt', '**/*.xml', '**/*.properties')
\end{Verbatim}
-You might know this approach from the Hibernates Criteria Query API or JMock. Of course the API of a task has to support this. The from, to and includes methods all return an instance of the resources object. All of Gradles build-in tasks usually support this configuration style.
+You might know this approach from the Hibernates Criteria Query API or JMock. Of course the API of a task has to support this. The from, to and includes methods all return an instance of the resources object. All of Gradle's build-in tasks usually support this configuration style.
But there is yet another way of configuring the resources task. It also preserves the context and it possibly offers the best readability. It is usually our favorite.
\begin{Verbatim}
@@ -79,9 +79,9 @@
\section{Summary} % (fold)
\label{sec:the_idea_behind_gradle_tasks}
-If you are coming from Ant, such an enhanced Gradle task as \emph{Resources} looks like a mixture between an Ant target and an Ant task. And this is actually the case. The separation that Ant does between tasks and targets is not done by Gradle. The simple Gradle tasks are like Ant's targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradles tasks share a common API and you can create dependencies between them. Such a task might be nicer to configure than an Ant task. It makes full use of the type system, is more expressive and easier to maintain.
+If you are coming from Ant, such an enhanced Gradle task as \emph{Resources} looks like a mixture between an Ant target and an Ant task. And this is actually the case. The separation that Ant does between tasks and targets is not done by Gradle. The simple Gradle tasks are like Ant's targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradle's tasks share a common API and you can create dependencies between them. Such a task might be nicer to configure than an Ant task. It makes full use of the type system, is more expressive and easier to maintain.
-% You might be wondering why the Resources task you have created above is not initialized with any default values. After all Gradle claims to offer build-by-convention. But which default values? The one we use for Java Projects? Or the one we use for other project types? What we have done above is to use a Gradle task in a stand alone fashion. It is open for anything. How Gradles tasks are integrated into a build-by-convention mechanism is what we are going to show in the next chapter.
+% You might be wondering why the Resources task you have created above is not initialized with any default values. After all Gradle claims to offer build-by-convention. But which default values? The one we use for Java Projects? Or the one we use for other project types? What we have done above is to use a Gradle task in a stand alone fashion. It is open for anything. How Gradle's tasks are integrated into a build-by-convention mechanism is what we are going to show in the next chapter.
% section the_idea_behind_gradle_tasks (end)
|