https://github.com/bbobcik/auderis-gradle-tools
Small additions for Gradle build system
https://github.com/bbobcik/auderis-gradle-tools
build-configuration gradle gradle-plugin semantic-versioning test-support
Last synced: 5 months ago
JSON representation
Small additions for Gradle build system
- Host: GitHub
- URL: https://github.com/bbobcik/auderis-gradle-tools
- Owner: bbobcik
- License: apache-2.0
- Created: 2016-07-04T06:02:48.000Z (almost 10 years ago)
- Default Branch: master
- Last Pushed: 2017-05-12T03:16:30.000Z (about 9 years ago)
- Last Synced: 2024-11-15T09:49:28.192Z (over 1 year ago)
- Topics: build-configuration, gradle, gradle-plugin, semantic-versioning, test-support
- Language: Java
- Size: 114 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# auderis-gradle-tools — Build system improvements
Small but useful additions for Gradle build system.
Keywords: `Gradle`, `plugin`, `semantic versioning`, `test support`
[](https://travis-ci.org/bbobcik/auderis-gradle-tools)
[](https://maven-badges.herokuapp.com/maven-central/cz.auderis/auderis-gradle-tools)
## Changelog
### 2.0.0
* Semantic versioning mechanism improved
### 1.0.1
* `SemanticVersion` class added
* Build system change (Gradle instead of Maven)
### 1.0.0 Initial release
* Test support plugin introduced
## Test Support Plugin
*Motivation:* Typically, software projects focus only on production code part, occasionally a test part
is included, too. However support for library objects' testing/validation in client environment is - as it
seems - a novel idea, which leads to a too common "reinventing the wheel". Basically, a developer who wants
to perform certain tests (also known as *assertions*) on library's objects is left to his own devices, which
results in reader-unfriendly, cumbersome assertion constructs. Compare the following test code:
```
Customer customer = ...
assertNotNull( customer.getLastOrder() );
assertTrue( !customer.getLastOrder().isClosed() );
```
with alternative
```
Customer customer = ...
assertThat( customer, hasLastOrderOpen() );
```
The difference is that author of the hypothetical `Customer` class spend some time providing an appropriate Hamcrest
matcher for a certain property (of course provided that the usefulness of the property warrants a dedicated matcher).
Obviously, the matchers and other components supporting tests must be published to be useful outside of their project,
but their inclusion into a production code bundle is deemed a bad design. **The solution and the raison d'etre of this
plugin is an idea that a library-type project should have 3 parts:**
* `src/main`: the library with production code
* `src/test-support`: a module that facilitates unit testing of the project's objects in a client environment,
e.g. Hamcrest matchers, JavaBeans property editors, JUnitParams annotations and converters etc.
* `src/test`: normal unit test code that has access to both production and test-support code
Of the mentioned 3 project parts, the library itself and the test support module would be published as artifacts.
The test support is distinguished by having artifact filename "appendix" set to `test_support`.
For example, the produced artifacts of a "FooBar" project would be:
* Production: `foobar-1.0.0.jar`
* Test support: `foobar-test_support-1.0.0.jar`
Plugin usage
```gradle
// build.gradle
buildscript {
// Define where to find the plugin module, e.g. mavenCentral()
}
apply plugin: 'cz.auderis.TestSupport'
dependencies {
...
testSupportCompile 'org.hamcrest:hamcrest-all:1.3'
...
}
```
## Semantic versioning
As specified in Gradle documentation, project/module version may be an object of any type. Gradle uses its
`toString()` to obtain the version string. However often there is a need for other, more detailed inspection
of version number structure.
When adopting [Semantic Versioning](http://http://semver.org/) approach, a convenient class is made available
by this library for Gradle scripts. The version may be defined either directly in the script or loaded from
an external resource, such as a file or even URL.
```gradle
import cz.auderis.tools.gradle.semver.SemanticVersion
// build.gradle
buildscript {
// Define where to find the plugin module, e.g. mavenCentral()
}
// Use direct specification
project.version = SemanticVersion.is("1.0.0-SNAPSHOT")
// Load version specification from a file
project version = SemanticVersion.from("version.txt")
```
An instance of `SemanticVersion` class has, among others, the following properties:
* `majorVersion` (with convenient alias `major`) returns first numeric part X from version X.Y.Z
* `minorVersion` (with convenient alias `minor`) returns numeric part Y from version X.Y.Z
* `patchRevision` (with convenient aliases `patch` and `patchLevel`) returns numeric part Z from version X.Y.Z
* `prerelease` is a boolean flag that indicates that either major version is 0 or there are pre-release identifiers
present (part P in version string X.Y.Z-P). There is an alias `preRelease` available as well.
* `stable` is a boolean flag that is effectively a negation of `prerelease` property
* `snapshot` is a boolean flag that indicates whether a special pre-release ID `SNAPSHOT` is present
in the version string (i.e. "1.4.2-SNAPSHOT")