search

roskenet / springboot-javafx-support

SpringBoot / JavaFX8 Integration
MIT License
419 stars 140 forks source link

Remove circular dependency to test project #60

Closed roskenet closed 6 years ago

roskenet commented 6 years ago

The support library and the test package (https://github.com/roskenet/springboot-javafx-test) reference themselves. This leads to a circular dependency that makes upgrading both harder than it should be.

This should be fixed.

octaviospain commented 6 years ago

Why not to merge it into this project?

roskenet commented 6 years ago

Yes, this would be an idea. But that mixes test classes with production code. I am not sure, if this is the best academic and architectural solution!?

octaviospain commented 6 years ago

If the intent is to provide a base class to test Spring Boot + JavaFX code, maybe is a good idea to include it in the production code as It will be available in the library for that purpose. I'm working in improving the tests, using JUnit 5. I'm trying to achieve the best approach covering the code and using this base class inside the project, I will push the changes this week.

roskenet commented 6 years ago

Great! Thanks for your effort!

octaviospain commented 6 years ago

I removed the dependency and I moved and renamed the class to SpringJavaFxTestingBase. As you can see, now using JUnit5, the class needs to use both SpringExtension and ApplicationExtension in order to load spring beans and construct the FxToolkit by TestFX, respectively. This forces that the class has to be in the test scope since both spring-test and test-fx dependencies remain there, and therefore the extensions cannot be referenced in the sources files.

The idea of providing the base test class as a library is good, but is not doable in this case. I suggest to leave the other library for JUnit4 tests and explain it there, and point in this project that that the way to test JavaFX + Spring Boot classes is following the usage of SpringJavaFxTestingBase class and let people copy it.

roskenet commented 6 years ago

Sooner or later this should be Java9-style-modularized anyways. When doing this, one should extract the API into its own module and jar. This will fix it.... someday ;-)