so dont you do that!

@ron Oh, fantastic! Let me know if you get stuck on anything, I have made some Maven plugins over the years. Maybe this is a good chance to investigate the ssh plugin as well. If you integrate it there, I can integrate the same into the Gradle plugin.

There has been several different standards/ways to create Maven plugin, make sure you pick the most recent layout.

🎉

Great work Ron!

@gtnarg Are you using spring in your tornadofx app?

yes

Does it look like how it's described in chapter 20

? @gtnarg

@User uploaded a file: Spring Configuration with additional override and commented: @ron The second override can be utilized as

val helloBean : HelloBean by di("beanName")

I actually am accessing tornadofx from a regular javafx application so I configure the DIContainer from java - so I haven't tested the above. I will test it in your example application when I have moment...

That second override is nice I should test it and put it in the guide

In #vertx Egor Ushakov from IntelliJ is discussing new feature for combining async stacks. If someone is interested, you can join the conversation.

@gtnarg do you mind if I use your example in the guide?

@ron - please do 🙂

@User uploaded a file: Untitled

It is quite common in the Spring world to name a bean like so:

xml
<bean id = "helloWorld" class = "com.tutorialspoint.HelloWorld">
     <property name = "message" value = "Hello World!"/>
</bean>

The bean is then accessible using the

id

. This can be done in tornadoFX too:

kotlin
class SpringExampleApp : App(SpringExampleView::class) {
    init {
        val springContext = ClassPathXmlApplicationContext("beans.xml")
        FX.dicontainer = object : DIContainer {
            override fun <T : Any> getInstance(type: KClass<T>): T = springContext.getBean(type.java)
	        override fun <T : Any> getInstance(type: KClass<T>, name: String): T = springContext.getBean(type.java,name)
        }
    }
}

The second

getInstance

uses both the type of the bean as the id of the bean. Instantiating a bean is down as:

val helloBean : HelloBean by di("beanName")

The second getInstance uses both the type

and

id of the bean. The bean can be injected by:

val helloBean : HelloBean by di("helloWorld")

(to be consistent with the xml).

@ron I use the name lookup (instead of type lookup) all the time to configure different objects w/o writing extra java code

It is quite common in the Spring world to name a bean like so:

xml
<bean id = "helloWorld" class = "com.tutorialspoint.HelloWorld">
     <property name = "message" value = "Hello World!"/>
</bean>

The bean is then accessible using the

id

. This can be done in tornadoFX too:

kotlin
class SpringExampleApp : App(SpringExampleView::class) {
    init {
        val springContext = ClassPathXmlApplicationContext("beans.xml")
        FX.dicontainer = object : DIContainer {
            override fun <T : Any> getInstance(type: KClass<T>): T = springContext.getBean(type.java)
	        override fun <T : Any> getInstance(type: KClass<T>, name: String): T = springContext.getBean(type.java,name)
        }
    }
}

The second

getInstance

uses both the type of the bean and the id of the bean. Instantiating a bean is down as:

val helloBean : HelloBean by di("helloWorld")

PR made

thanks for that example Grant, makes the chapter even better

Great work, guys!

Somebody feeling up for a Spring screencast? 😁

my distaste of Spring would shine through 😉

If you have to spit every time you say Spring we should probably recruit someone else for this task. hehe

I would want to wash my mouth everytime I say it

I used to be a real spring admirer, but (IMHO) they have made it too complex, to overengineered

I was actually really relieved when I discovered how light Java EE was. I swapped out Spring and never looked back.