Open DanySK opened 3 years ago
I'd like to switch to gradle and follow DanySK's suggestion. Please feel free to take a look at this branch which I use already in my development. I think it should be even possible to use both: pom and gradle.build in parallel for a period of time, allowing for a smooth transition (at least my idea can handle the switch with some tweaking/refreshing)
Uhmm... @JacekWicka I think I might take over from you branch and just publish this under one of the groups I manage on Central.
If you guys are able to put some hours into this I'd be more than happy to grant you access to the project so you can push it forward. If releases are prepared I will of course push them to Maven Central, or we could set up access so you can do it directly.
It would be great someone release this, so people can try out things easily.
@JacekWicka I forked your branch and added a CI, but it gets stuck under Linux.
@DanySK any error messages?
For the CI structure see: https://github.com/DanySK/tornadofx2/blob/master/.github/workflows/build-and-deploy.yml
AsyncTest > latch FAILED
java.lang.RuntimeException at AsyncTest.kt:19
Caused by: java.lang.UnsupportedOperationException at GtkApplication.java:173
AsyncTest > runAsync FAILED
java.lang.RuntimeException at AsyncTest.kt:19
Caused by: java.lang.UnsupportedOperationException at GtkApplication.java:173
AsyncTest > runAsyncWithOverlay FAILED
java.lang.RuntimeException at AsyncTest.kt:19
Caused by: java.lang.UnsupportedOperationException at GtkApplication.java:173
There was no Gradle wrapper in tracking btw. It should be tracked.
OIC: UI tests on CI needs some extra love... Try without tests first.
@DanySK has you seen this: https://github.com/TestFX/TestFX#continuous-integration-ci
@DanySK I added travis CI to that gradle_build branch and after some tweaking got it up and running. The important points here are:
# headed
- _JAVA_OPTIONS="-Dtestfx.robot=glass"
# headless using monocle
- _JAVA_OPTIONS="-Djava.awt.headless=true -Dtestfx.robot=glass -Dtestfx.headless=true -Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw"
services:
- xvfb
and build.gradle.kts
//headless
testRuntimeOnly("org.testfx:openjfx-monocle:jdk-12.0.1+2") // jdk-9+181 for Java 9, jdk-11+26 for Java 11
and yes, using version jdk-12.0.1+2 here is not a bug... Hope this helps to setup your autodelivery scripting
Great work @JacekWicka - I've desperately wanted to see a gradle version go up. The programmer recoils in horror when faced with anything resembling XML markup.
There have been numerous discussions over the past year or so about someone coming up and taking the mantle for tornadofx. Edvin has moved on to bigger and better things and he seems open to letting others take over.
I'm all for merging your branch and putting a big fat message on the tornadofx git page telling people to come here. There's lots of additions and changes I would like to make but the horrors of maven have been enough to scare me away.
The community desperately needs some kind soul to offer to take up the responsibility of becoming a project maintainer.
Hey! Just want to chime in to reiterate that I would love for someone to keep the project alive. I still use it (and enjoy it!) though I can't find enough time to contribute in any meaningful way anymore.
Thx @SKeeneCode.
There's lots of additions and changes I would like to make but the horrors of maven have been enough to scare me away.
Same here :) Just created that pull request #24
I would love for someone to keep the project alive, @edvin
How should that work? I would like to push forward and get it released on Maven Central (to start with), as I plan to use tornadofx in at least another two upcoming projects. (kind of smart clients for ktor-services).
Meantime, I've played with travis and by going through this tutorial: https://getstream.io/blog/publishing-libraries-to-mavencentral-2021 could stage the jar automatically on MC under my coordinates. But this process requires sharing gpg key and credentials with travis. Not sure if that is the right way to go here. Suggestions?
I'm more than willing to continue doing the releases, no problem. The infrastructure is set up and ready to go. Then we can keep the project coordinates as well, and I'd be slightly more involved than I am at the moment, without it eating too much time for it to be an issue on my end.
@edvin I am ok with that, but still - what is your idea for
I would love for someone to keep the project alive
You didn't commented on #16. IMHO there is a need for more communication and also guidelining to get people involved.
Ya if there was more of contributors guideline then it make it easier for others to get involved. I used tornadofx for a while a couple years back and was awesome. If there was more information on the purpose of this report and how to contribute early on I would consider seeing what I can do as well... more on the implementation side.
Did this amount to a release on Maven Central? Also is TFX2 at a stable state?, can I migrate from TFX to TFX2?
Hi, i believe it would make sense to release even betas on Maven Central. The project could adopt an agile versioning system and release process. The build/release could be made more agile via Gradle, see #7, in which case the versioning can be automated via GitSemVer.
This could begin by releasing a 0.1.0 version of tornadofx2, whatever its state.