Griffon Mythbusthers

I’ve seen myths surrounding the Griffon framework appear over the years, I think it’s time to set the record straight and dispel any misinformation.

Myth: Griffon projects require Gradle as a build tool.

Incorrect. The preferred choice for building Griffon projects is Gradle if you happen to use a Lazybones template to bootstrap the project, however you may use Apache Maven, Apache Ant, or any other JVM build tool (even Make if you really want to) to build a Griffon project.

Myth: Griffon projects can only be bootstrapped with Lazybones.

Incorrect. The preferred choice for bootstrapping a Griffon project is Lazybones but you can also use Apache Maven archetypes to bootstrap a Maven only project. The complete list of archetypes can be found at the griffon-archetypes repository hosted by Bintray’s JCenter. These archetypes are also available at Maven Central. Currently available archetypes are:

    griffon-javafx-groovy-archetype
    griffon-javafx-java-archetype
    griffon-lanterna-groovy-archetype
    griffon-lanterna-java-archetype
    griffon-pivot-groovy-archetype
    griffon-pivot-java-archetype
    griffon-swing-groovy-archetype
    griffon-swing-java-archetype

Select a starting archetype from the list and invoke the archetype:generate goal

$ mvn archetype:generate
    -DarchetypeGroupId=org.codehaus.griffon.maven
    -DarchetypeArtifactId=griffon-javafx-java-archetype
    -DarchetypeVersion=<archetype-version>
    -DgroupId=org.example
    -DartifactId=app
    -Dversion=1.0.0-SNAPSHOT

Myth: Griffon projects must follow a specific directory/file structure.

Incorrect. Both templates and archetypes suggest a recommended directory/file structure however developers have free range to decide how they want their project structure to look like; one can even remove many (or all) conventions suggested by the templates/archetypes and use standard Gradle/Maven conventions, as shown in this tutorial.

Myth: Griffon has a Gradle plugin but there’s no Maven equivalent.

Correct. Gradle’s built-in plugins provide more behavior out of the box than what can be achieved by Maven’s core support. However the Lazybones templates and Maven archetypes provide enough configuration for a Maven build that enables compatible and equivalent behavior as observed in their Gradle counterparts.

Myth: There’s no IDE support for Griffon.

Correct. Every Griffon project is a regular Gradle/Maven/Ant/… project and as such it does not require specific/additional IDE support. The one exception is IntelliJ as it provides support for an earlier version of Griffon (series 1.x) that’s no longer compatible with series 2.x and future ones. Do not use this plugin, it’s not needed at all.

Myth: Griffon 2.x can’t be installed used SDKMan as it only lists up to version 1.5.0.

Correct. Series 1.x used to provide its own command line interface. Series 2.x relies on external build tools (such as Gradle and/or Maven) thus it no longer requires special support from SDKMan.

Myth: Griffon is primarily a Swing application framework, JavaFX is not supported at 100%.

Incorrect. Series 1.x began life as a Swing only application framework, with JavaFX support added at a later stage. Series 2.x was redesigned from scratch to support multiple UI toolkits without pushing Swing abstractions to the others. The current list of supported UI toolkits contains: Swing, JavaFX, Apache Pivot, Lanterna.

Myth: You must be proficient in Apache Groovy to use Griffon.

Incorrect. Series 1.x started as a fork of the Grails codebase and thus inherited a lot from Grails, including the preference for Groovy as the main language of choice. Series 2.x was rewritten from scratch with Java developers in mind, delivering a set of artifacts that do not force the usage of Apache Groovy in any way. Developers are free to choose the main language, be it Java, Apache Groovy, Kotlin, or a combination of any of the three. Additional JVM languages may be supported in the future.

Myth: Griffon forces the MVC pattern for structuring an application.

Incorrect. While Griffon does provide base artifacts such as Model, View, and Controller, whose responsibilities follow the PMVC design pattern it is possible to use different design patterns such as MVP, MVVM, classic MVC, or others. See this tutorial for an explanation.

Myth: Griffon can not create applications that run on mobile platforms.

Correct. Some of the core APIs rely on the java.beans package which happens to be a banned API in the Android space. The only Java based UI toolkit capable of running on both Android and iOS devices is JavaFX, thanks to Gluon’s jfxmobile support. Basilisk is a fork of the Griffon codebase that targets desktop and mobile platforms with JavaFX support only, using Gluon’s jfxmobile, tying the framework to Gradle as a build tool. Series 3.x of Griffon will forego usage of the java.beans package and provide a mobile friendly option.

For additional information on Griffon, please refer to the following links

 

Trackbacks/Pingbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

ˆ Back To Top