Is this project still alive?

[Mrodent]

I see the latest commit dates from 2019-07-30, so I'm full of hope.

I just included this as a dependency in build.gradle: implementation 'org.groovyfx:groovyfx:8.0.0' ./gradlew build gives:

Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find org.groovyfx:groovyfx:8.0.0.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/org/groovyfx/groovyfx/8.0.0/groovyfx-8.0.0.pom
       - https://repo.maven.apache.org/maven2/org/groovyfx/groovyfx/8.0.0/groovyfx-8.0.0.jar
     Required by:
         project :

I go to Maven Central: it appears to be there. Baffled.

Then I see here that you say there is a newer version, 9.0.0 snapshot (not a release). I try this, I also try jcenter instead of maven central. All attempts fail.

I see it is possible to download the 8.0.0. jar from maven central. Done that. I am also cloning the latest commit, on the assumption that this is your latest stable snapshot...

oops: after cloning, and ./gradlew build, fails:

> Task :licenseGradle FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':licenseGradle'.
> License violations were found: /home/chris/.groovy/groovyfx/9_0_0_snapshot/groovyfx/gradle/code-quality.gradle,/home/chris/.groovy/groovyfx/9_0_0_snapshot/groovyfx/build.gradle,/home/chris/.groovy/groovyfx/9_0_0_snapshot/groovyfx/settings.gradle,/home/chris/.groovy/groovyfx/9_0_0_snapshot/groovyfx/gradle/demo.gradle}

Please let me know what's going on with this project & why maven central is not working.

[russel]

I'd suggest that given this project hasn't really been updated since the release of JDK8, the answer is it is stalled (or worse). Clearly the original developers of this project are no longer developers of this project, so either new people need to step in to enliven it, or it will have to be considered dead.

[Mrodent]

OK thanks

[aalmiray]

Hi, I'm the one currently maintaining the project (at least the build). All I can say is that in previous months it was quite hard to support Java 9+ project with Gradle as it lacks the proper support for JPMS and Multi Release JARs for example. Some improvements have been made by the community driven java-modularity plugin. I've been meaning to get back to the build to see if the roadblocks have been sorted out. Give me a couple of days to figure this out.

If all goes well we may get a release that's JavaFX11/JDK11 compatible but not necessarily JDK8 compatible.

[russel]

@aalmiray I have pulled away from the Groovy/GPars/GroovyFX community and activity, but would be happy to give a hand making GroovyFX JDK11 compatible if I am able to. GroovyFX being stuck in the JDK8 position was a bit of a death knell for it.

[Mrodent]

@aalmiray Thanks for letting me know. I'm currently on Java 11.

Also, I'm just trying to understand the purpose of this groovyfx project. I checked out what you say here: http://groovyfx.org/.

I found this project a couple of days ago when I was tearing my hair out trying to understand how to get Gradle + Java11 + Groovy app and test code + JavaFX to work together (and result in a JavaFX-bundled self-contained executable).

A couple of people came up with the answer (see comments here), and I will obviously be coding everything, including JavaFX, in Groovy, not Java. Yesterday I also got TestFX up and running in a first project - again using Groovy.

So, I ask this as a dedicated Groovy fan, what does your project give us? From groovyfx.org it appears you can write a script without defining an Application class. Anything else? Have you in fact written it with TestFX testing in mind at all?

[novakmi]

Currently I use latest sources with my JavaFX project and JDK 11. I clone groovyfx repo next to my project directory and use

 includeBuild('../groovyfx')

this seems to work well. What does not work is jlink Gradle plugin :-(, not sure if this is because of this.

Can we expect groovyfx-11 (or at least groovyfx-11.-SNAPSHOT) to be published in JCenter (Maven) repository?

[aalmiray]

@novakmi this project does not work with jlink at the moment ad Groovy itself is not yet compatible with JPMS, that is, its binaries still have split packages and are missing module-info.

There are a few items that need to be finished before producing a release. You may use jitpack.io in the meantime to build and configure a snapshot build. Composite builds do not work with jitpack.

[aalmiray]

@mrodent it might shock you but personally I’d never write a JavaFX application using the script approach; I don’t find it suitable for long term development, I’d rather choose an application framework for that.

There are many choices out there, the one for me is http://griffon-framework.org for obvious reasons (I’m one of the founders). Though writing views in GroovyFX is one option I’d pick a combination of FXML and scripting, as shown here http://griffon-framework.org/tutorials/4_javafx_views.html

[Mrodent]

@aalmiray I agree with you, Groovy scripts are, I think, largely for checking stuff to do with the language. For "sys admin" tasks I personally prefer Python scripts (better than BASH in so many ways), so Groovy scripts are kind of a solution without a question for me.

I don't quite know about a "framework" for JavaFX. I find it's (now) easy enough to spin up a Gradle project and do it that way. You can also include TestFX (testfx-spock is my preference) for the testing classes. Standalone SceneBuilder for the FXML. So I don't seem to need any framework currently.

Again, for this reason I don't understand the purpose of groovyfx. NB jlink is not going to be compatible with Groovy for a very long while: even Groovy 3 cannot handle Java 9+ modules. It appears this is an "aspiration" for Groovy 4... (!)

[novakmi]

@aalmiray Thanks for jitpack suggestion. My application is not too complicated and to tell the truth, I find GroovyFX more easier than FXML for this. I did not run into any problem yet. Yes, solution may be to generate FXML with groovy XML builder. This might be similar, but still more complicated. I'm not big fan of XML for something that can be expressed easier in a code (like groovy builder). I think it allows better reuse and flexibility. Anyway, thanks for (still) looking into this project.

[Mrodent]

I just had a look at that griffon link. Thanks, that was interesting. As something of a newb when it comes to JavaFX I'm not sure why precisely I would want to construct a UI (window, dialog, etc.) using Groovy when a tool like SceneBuilder exists: I take precisely 0 interest in the XML generated by this tool, but the point is that a basic UI container/component lends itself naturally to being expressed in an XML "tree", unlike many other use cases of XML.

[msgilligan]

I evaluated this project in 2016, but ended up deciding to go with straight Java (at least initially). At the time I was especially interested in the binding support annotations -- and I still am -- I think they would be useful as a separate module. They could be especially powerful if they can be made compatible with @CompileStatic and the alpha @POJO annotation.

These days I'm using JDK 15 (and planning to move to JDK 16 asap) with JavaFX 11 and am using the B.A. JLink Plugin to build native bundles and everything is as friendly to Java Module System as possible. (I'm also using Supernaut.FX for lightweight DI).

My (admittedly self-interested) advice is to require Groovy 4 or later for the GroovyFX version 11 that is currently under development. I'm spread way too thin ("my side projects have side projects" 😂) but if work were started on the binding support annotations using Groovy 4, I would at least take them for a test drive and possibly be able to contribute in minor ways.