This tutorial describes how a Griffon application can be build without using the griffon Gradle plugin. It also shows that how all source and resources directories can be condensed into a minimum set of directories.

1. Directory Layout

Griffon relies on Lazybones templates in order to boostrap a brand new project or create additional artifacts. However this does not mean that Griffon projects must be created using the templates; as a matter of fact is possible to create a project by conventional Gradle means, or even by hand. The project doesn’t even have to comply with the standard Griffon structure, it can use the standard Java/Groovy project layout that Gradle understands. The following listing shows this layout, with all sources for a simple application already inside their respective directories

├── build.gradle                                                 (1)
├── gradle                                                       (2)
└── src
    ├── main                                                     (3)
    │   ├── java
    │   │   ├──
    │   │   └── org
    │   │       └── example
    │   │           ├──
    │   │           ├──
    │   │           ├──
    │   │           ├──
    │   │           └──
    │   └── resources                                            (4)
    │       ├── META-INF
    │       │   └── griffon
    │       │       ├── griffon.core.artifact.GriffonController
    │       │       ├── griffon.core.artifact.GriffonModel
    │       │       ├── griffon.core.artifact.GriffonService
    │       │       └── griffon.core.artifact.GriffonView
    │       ├──
    │       ├── griffon-icon-128x128.png
    │       ├── griffon-icon-16x16.png
    │       ├── griffon-icon-24x24.png
    │       ├── griffon-icon-256x256.png
    │       ├── griffon-icon-32x32.png
    │       ├── griffon-icon-48x48.png
    │       ├── griffon-icon-64x64.png
    │       ├── griffon.png
    │       ├──
    │       ├──
    │       ├── org
    │       │   └── example
    │       │       └── sample.fxml
    │       └──
    └── test                                                     (5)
        └── java
            └── org
                └── example
1 build file
2 additional build files
3 main sources
4 main resources
5 test sources

We begin by looking at root directory, where we find the main build file 1 paired with some additional build scripts 2 that take care of configuring this project for JavaFX, as well as setting up integration and functional tests. All application sources are located in the standard location for a Java project, that is src/main/java 3; main resources are found in their conventional location too 4. Notice that special metadata files are located there too. Test sources do follow the same conventions 5 so they are located inside src/test/java. Finally we see the sources for integration 6 and 7 functional tests, which follow the paths configured by the additional build scripts 2.


2. Metadata Files

Usually Griffon projects will automatically generate metadata files associated with Griffon artifacts, thanks to the usage of the @ArtifactProviderFor annotation in combination with {link_jipsy}. But given that we did not define a dependency in provided scope for {link_jipsy} we must have to write these files by hand. The catch is that these files must be updated every time an artifact is added, renamed, or deleted.



3. Build Files

There are a handful of ways to define project properties for a Gradle project. The cleanlest one is to define these properties on a file named, whose contents can be found in the next listing
group               = org.example
version             = 0.1.0-SNAPSHOT
griffonVersion      = 2.16.0-SNAPSHOT
slf4jVersion        = 1.7.32
sourceCompatibility = 1.8
targetCompatibility = 1.8

The next sections describe the manin build file segreggating its blocks by responsibilities, as well as the additional script files that deal with more functionality.


3.1. Main

There’s little to be done in terms of plugin configuration. You need the java plugin at the very least. The other ones listed next allow you to keep an eye on dependency versions and tidy up license headers on files

Plugin configuration
plugins {
    id 'java-library'
    id 'application'
    id 'idea'
    id 'com.github.ben-manes.versions' version '0.39.0'
    id 'com.github.hierynomus.license' version '0.14.0'

mainClassName = 'org.example.Launcher'

Let’s have a look at the project dependencies. This being a JavaFx project means we need griffon-javafx-2.16.0.jar as a dependency. We also need an implementation for dependency injection, this is why griffon-guice-2.16.0.jar is added to the list. We round up with a concrete implementation of slf4j-api, such as slf4j-log4j12. Finally, regarding tests, we would need griffon-javafx-test-2.16.0.jar plus a few others to make writing tests easier.

Dependencies configuration
repositories {

dependencies {
    api "org.codehaus.griffon:griffon-javafx:${griffonVersion}"
    api "org.codehaus.griffon:griffon-guice:${griffonVersion}"
    api 'org.kordamp.ikonli:ikonli-javafx:2.1.1'
    api 'org.kordamp.ikonli:ikonli-fontawesome-pack:2.1.1'
    api 'org.kordamp.bootstrapfx:bootstrapfx-core:0.2.2'

    runtimeOnly "org.slf4j:slf4j-simple:${slf4jVersion}"

    testImplementation "org.codehaus.griffon:griffon-javafx-test:${griffonVersion}"
    testImplementation 'pl.pragmatists:JUnitParams:1.1.1'
    testImplementation 'org.mockito:mockito-core:2.15.1'

Every Griffon application has a set of resource files; contains useful values such as the name of the application, its version, and the current Griffon version in use. These values can be obtained from the build and passed into resource files. We use Gradle’s standard mechanism for processing resources.

Resources configuration
processResources {
    filesMatching(['**/*.properties','**/*.xml']) {
            'application_name'   :,
            'application_version': project.version,
            'griffon_version'    : griffonVersion