.
├── build.gradle (1)
├── gradle (2)
├── gradle.properties
└── src
├── main (3)
│ ├── java
│ │ ├── Config.java
│ │ └── org
│ │ └── example
│ │ ├── Launcher.java
│ │ ├── SampleController.java
│ │ ├── SampleModel.java
│ │ ├── SampleService.java
│ │ └── SampleView.java
│ └── resources (4)
│ ├── META-INF
│ │ └── griffon
│ │ ├── griffon.core.artifact.GriffonController
│ │ ├── griffon.core.artifact.GriffonModel
│ │ ├── griffon.core.artifact.GriffonService
│ │ └── griffon.core.artifact.GriffonView
│ ├── application.properties
│ ├── 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
│ ├── log4j.properties
│ ├── messages.properties
│ ├── org
│ │ └── example
│ │ └── sample.fxml
│ └── resources.properties
└── test (5)
└── java
└── org
└── example
├── SampleControllerTest.java
└── SampleServiceTest.javaTutorial 6::Minimalistic Build
Agenda
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
| 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.
META-INF/griffon/griffon.core.artifact.GriffonController
org.example.SampleControllerMETA-INF/griffon/griffon.core.artifact.GriffonModel
org.example.SampleModelMETA-INF/griffon/griffon.core.artifact.GriffonService
org.example.SampleServiceMETA-INF/griffon/griffon.core.artifact.GriffonView
org.example.SampleView3. 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 gradle.properties, whose contents can be found in the next listing
gradle.properties
group = org.example
version = 0.1.0-SNAPSHOT
griffonVersion = 2.16.0-SNAPSHOT
slf4jVersion = 1.7.32
sourceCompatibility = 1.8
targetCompatibility = 1.8The 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 {
mavenCentral()
mavenLocal()
}
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; application.properties 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']) {
expand(
'application_name' : project.name,
'application_version': project.version,
'griffon_version' : griffonVersion
)
}
}