The docs project produces the user manual, DSL reference, javadoc and release notes (as well as some other minor bits).
The following is some help for working with the docs, all file paths are relative to this directory unless specified otherwise.
The release notes are generated from src/docs/release/notes.md
.
Every h2
tag and h3
will be listed in the generated TOC.
After every h3
all content after the first element (usually a p
) will be collapsed/expandable, up until the next h3
, or h2
.
After every h4
all content will be collapsed/expandable, up until the next h4
, h3
or h2
.
An h3
may include an incubating marker (i)
at the end of its text to indicate that the feature is incubating.
Here's an example:
## h2 New and Noteworthy
### h3 Some feature (i)
This is some incubating feature.
#### h4 Some detail
This detail about the feature is collapsed. The reader can expand it if they are interested.
Run the viewReleaseNotes
task to generate the release notes, and open them in your browser (requires Java 6).
You can run the editReleaseNotes
task to open the raw markdown notes in whatever editor is registered for this file type (requires Java 6).
The source for the user manual lives @ src/docs/userguide
, and is authored in Asciidoctor.
To generate the user manual and see your changes, run:
./gradlew :docs:userguide
This will generate:
- A multi-page HTML manual in
build/docs/userguide
for each chapter. There is a 1-1 mapping from.adoc
file to.html
file. - A single-page HTML manual at
build/docs/userguide/userguide_single.html
- A PDF at
build/docs/userguide/userguide.pdf
Note that PNG files in the source are generated from ".graphml" files in the same directory. You can edit these files with tools like yEd and then generate the associated PNG.
If you just need to see a change to one of the userguide sections, try:
./gradlew :docs:userguide -x :docs:userguideSinglePage
To write a chapter in Asciidoctor format, simply place it in src/docs/userguide
called <chapter>.adoc
.
You will find these references useful when authoring AsciiDoc:
To write a chapter in Asciidoctor format, simply place it in src/docs/userguide
called <chapter>.adoc
.
Samples and output belong under src/samples
and are typically included in the user manual. This is a typical example:
This shows Groovy and Kotlin sample projects under "sample-dir" which is defined as "$projectDir/src/samples".
subprojects/docs/src/samples/
└── userguide/initScripts/customLogger/
├── customLogger.out
├── customLogger.sample.conf
├── groovy
│ ├── build.gradle
│ ├── init.gradle
│ └── settings.gradle
└── kotlin
├── build.gradle.kts
├── customLogger.init.gradle.kts
└── settings.gradle.kts
Note here that there are 2 sample projects under userguide/initScripts/customLogger/
: one for the Groovy DSL and one for Kotlin DSL. Also note that there is only 1 customLogger.sample.conf
file that tells Exemplar how to execute both groovy and kotlin samples, with 1 customLogger.out
file proving the output is identical between the two.
.Customizing what Gradle logs
====
include::sample[dir="userguide/initScripts/customLogger/groovy",files="init.gradle[]"]
include::sample[dir="userguide/initScripts/customLogger/kotlin",files="customLogger.init.gradle.kts[]"]
====
[.multi-language-text.lang-groovy]
----
$ gradle -I init.gradle build
include::{samplesPath}/userguide/initScripts/customLogger/customLogger.out[]
----
[.multi-language-text.lang-kotlin]
----
$ gradle -I customLogger.init.gradle.kts build
include::{samplesPath}/userguide/initScripts/customLogger/customLogger.out[]
----
Let's break down this example to explain:
- Enclosing
====
around the sample includes groups these samples and collapses them include::sample
: invokes theSampleIncludeProcessor
asciidoctor extension, with adir
relative tosrc/samples/
, and a list offiles
separated by;
(only 1 in this example), each with optionaltags=...
(like Asciidoctor's tags mechanism). We write this once for each DSL dialect. This notes to our front-end code to group these 2 samples and show them with selector tabs.[.multi-language-text.lang-groovy]
: Most times the gradle command is identical between Groovy and Kotlin samples, but in this case we need to use[.multi-language-text.lang-*]
that our CSS will collapse and switch for the DSL of choice. This is case-sensitive. You can use this construct for any 2 sibling blocks!
It is possible to embed sample sources, commands, and expected output directly in the Asciidoc (or a mixture of embedded and include
d), but we don't use this for the user manual yet. See the Exemplar documentation if you're interested in this.
The DSL reference is authored in Docbook syntax, with sources under src/docs/dsl
.
Much of the content is extracted from code doc comments.
To build it, run:
./gradlew :docs:dslHtml
The output is available under build/docs/dsl
.
See the docbook reference for a list of all available tags.
This is an inline element which adds a link to the API documentation for a particular class or method.
You can use the <apilink class='org.gradle.api.Project' /> interface to do stuff.
The link will point to the DSL reference for the specified class, if available. Otherwise, it will point to the javadoc for the class.
To link to a method:
<apilink class='org.gradle.api.Project' method="apply(java.util.Map)" />
To build these, run:
./gradlew :docs:javadoc
The output is available within build/docs/javadoc
.
There is a convenience task to build all of the documentation:
./gradlew :docs:docs