currently the dependencies of tornadofx are quite small which I personally like

@ron Yeah, it just depends on the json lib, and I might even remove that if I implement the writable json support.

@ron The dependency wouldn't really make the project bigger, as code would be removed from tornadofx, and the java bytecode generated is almost always smaller than the kotlin version.

tbh my opinion is we should either have it all in tornadofx or not in tornadofx

This is not something I'm going to explore now though.

@ron That is my gut feeling as well.

but having the builder in tornadofx and the actual thing that gets build not feels wrong

@edvin its not about making the project smaller or bigger, its about keeping the dependencies in check

This needs to be investigated more, and it's not on my radar right now anyways. Too much to do. I feel that the IDEA plugin needs love the most.

one thing I always hated in spring is the fact that it depends on 75% of maven-central

and it can get you in a nice dependency hell

Hehe, yeah. My initial vision was "a single, small library, all in one package".

I like that vision

I may sound too architecty like but you should write down your vision and mission as tornadofx is growing in functionality and popularity

you will get more PR's and having a vision/mission will help

tornadofx can be built with the java classes included - no dependency needed. The tornadofx-controls library could be created by extracting the java classes.

@gtnarg Ah, that's what you meant. Sure, that's a nice way to go.

extract as in still having one code base, but generating 2 jars from it?

@ron We should probably work on a mission statement together.

Yeah, that's how I understood it.

Maybe we can even leverage Jigsaw for this.

@edvin I think Maven can create multiple jars with only subsets in it

@ron are you thinking of profiles? ex a Java profile and a Kotlin profile?

yeah that could be a way

@gtnarg if you had both a tornadofx.jar and a tornadofx-controls.jar on the classpath, you could use any public Java class that compiles and not involve Kotlin unless one of the Java classes were calling Kotlin classes

I don't imagine we'll do this before Java 9 anyways, so we probably investigate this when we do Jigsaw.

yeah i’m curious about what Java 9 means for Maven

One of the Maven guys did an in depth talk about that a while ago. Bottom line is that they have it under control.

that’s good to know. i’ll look for some slides.

@gtnarg I think for tornadofx-controls developers though, they should code in Kotlin instead of being held back by Java. You can call Kotlin classes with Java and the best implementation of TornadoFX is to transition to it completely, even if you have to operate in a hybrid mode for some period of time (potentially long).