Slicing configuration in @SpringBootApplication class to area specific configuration files about devon4j HOT 4 CLOSED

Hi @AbhayChandel! Thanks for your suggestion to improve.
We have had discussions like this a lot already. Still there is no easy conclusion or agreement.
Can we get even more precise about the reasons, rationales, and requirements?

• Is it preformance? We have learned that the suggested "optimization" is making the performance of running all tests together even a lot worse. As CI speed is crucial today this should be considered carefully. Of course the performance for a developer running a single tests would be improved by what you suggest. Where this is really important write module tests that do not need spring at all and are fast.
• Is it clearer feedback what is broken? Maybe this could be improved, but my experience is such that you need to have green tests. Whenever there is a bug revealed by the tests, they are not green anymore. Wheter 1 test fails or 1000 test fails does not make the big different. You have to fix asap. Of course when only 1 test fails it is easier to trace down the error. But when it is related to spring misconfig, I never hand issues finding the reason. The name of the failed test never helped. I run any failing test and read the stacktrace. With spring I can immediately tell what the problem is and how to fix it (except for 2 exception messages I hit in my life that are very rare).
• Are you suggesting to split by layer? Or by component? If you would split by both, you would end up with a mess of many configs that are unmaintainable. Splitting by component does not really help that much reducing the amount of bootstrapping. Splitting by layer can help a little but this is leading to my first point about performance. As you are talking about slices I assume you mean splitting by component.
• Anyting else?

from devon4j.

So after discussing this personally I now better understand:

• We will not create artificial test configurations for spring
• Instead we only try to "split" the configs from the SpringBootApp to smaller units and let the SpringBootApp assemble these units together.
• As I am not entirely sure how well this will work with spring boot without creating redundancies and increase maintenance efforts we agreed to creating a feature branch and PR for my-thai-star as a demo of this idea.
• If this works out as planned I am more than welcome that we merge the PR into my-thai-star and we also re-integrate the required changes into devon4j (archetype).
• Once we have this sliced/modularized config feature, we have the opportunity to use smaller units in JUnit tests to make that single test startup much faster when running isolated. Still projects have the freedom of choice to use the entire app as context configuration. This way we can experiment with the new feature and collect valuable experience. If we are having better success with the smaller config units we can change the documentation and propagate this also as a best practice.

Thanks for your ideas how to make devonfw better. I love all this kind of innovations and ideas that are going beyond the regular "getting issues done". So I very much appreciate it. Sorry, also for my sceptics. I do not want to block any innovation. Just was trying to be a little cautious cause of my experience I made with similar ideas in this area and want to stick to our solid principle:
https://github.com/devonfw/devon4j/wiki/architecture#key-principles

from devon4j.

I removed the milestone. If we are fast and make it into 3.1.0 I am more than happy to re-add it. Otherwise it should not block the release.

from devon4j.

If there is no further feedback we will most probably reject and close this issue.

from devon4j.