|
@@ -214,7 +214,7 @@ If your changes affect only the documentation, run:
|
|
|
```sh
|
|
|
./gradlew -p docs check
|
|
|
```
|
|
|
-For more information about testing code examples in the documentation, see
|
|
|
+For more information about testing code examples in the documentation, see
|
|
|
https://github.com/elastic/elasticsearch/blob/master/docs/README.asciidoc
|
|
|
|
|
|
### Project layout
|
|
@@ -305,6 +305,39 @@ the `qa` subdirectory functions just like the top level `qa` subdirectory. The
|
|
|
Elasticsearch process. The `transport-client` subdirectory contains extensions
|
|
|
to Elasticsearch's standard transport client to work properly with x-pack.
|
|
|
|
|
|
+### Gradle Build
|
|
|
+
|
|
|
+We use Gradle to build Elasticsearch because it is flexible enough to not only
|
|
|
+build and package Elasticsearch, but also orchestrate all of the ways that we
|
|
|
+have to test Elasticsearch.
|
|
|
+
|
|
|
+#### Configurations
|
|
|
+
|
|
|
+Gradle organizes dependencies and build artifacts into "configurations" and
|
|
|
+allows you to use these configurations arbitrarilly. Here are some of the most
|
|
|
+common configurations in our build and how we use them:
|
|
|
+
|
|
|
+<dl>
|
|
|
+<dt>`compile`</dt><dd>Code that is on the classpath at both compile and
|
|
|
+runtime. If the [`shadow`][shadow-plugin] plugin is applied to the project then
|
|
|
+this code is bundled into the jar produced by the project.</dd>
|
|
|
+<dt>`runtime`</dt><dd>Code that is not on the classpath at compile time but is
|
|
|
+on the classpath at runtime. We mostly use this configuration to make sure that
|
|
|
+we do not accidentally compile against dependencies of our dependencies also
|
|
|
+known as "transitive" dependencies".</dd>
|
|
|
+<dt>`compileOnly`</dt><dd>Code that is on the classpath at comile time but that
|
|
|
+should not be shipped with the project because it is "provided" by the runtime
|
|
|
+somehow. Elasticsearch plugins use this configuration to include dependencies
|
|
|
+that are bundled with Elasticsearch's server.</dd>
|
|
|
+<dt>`shadow`</dt><dd>Only available in projects with the shadow plugin. Code
|
|
|
+that is on the classpath at both compile and runtime but it *not* bundled into
|
|
|
+the jar produced by the project. If you depend on a project with the `shadow`
|
|
|
+plugin then you need to depend on this configuration because it will bring
|
|
|
+along all of the dependencies you need at runtime.</dd>
|
|
|
+<dt>`testCompile`</dt><dd>Code that is on the classpath for compiling tests
|
|
|
+that are part of this project but not production code. The canonical example
|
|
|
+of this is `junit`.</dd>
|
|
|
+</dl>
|
|
|
|
|
|
Contributing as part of a class
|
|
|
-------------------------------
|
|
@@ -337,3 +370,4 @@ repeating in this section because it has come up in this context.
|
|
|
|
|
|
[eclipse]: http://www.eclipse.org/community/eclipse_newsletter/2017/june/
|
|
|
[intellij]: https://blog.jetbrains.com/idea/2017/07/intellij-idea-2017-2-is-here-smart-sleek-and-snappy/
|
|
|
+[shadow-plugin]: https://github.com/johnrengelman/shadow
|