search

spring-io / start.spring.io

https://start.spring.io
Apache License 2.0
2.21k stars 900 forks source link

Provide some indication to the user that the Java version has been or will be downgraded #250

Open wilkinsona opened 5 years ago

wilkinsona commented 5 years ago

There are a few scenarios when the Java version is silently downgraded. For example, when Kotlin is selected as the language, Java 8 will always be used. Another example in the future will be when Java 13 is offered. Gradle won't support Java 13 until 6.0 so a downgrade may be necessary in the interim.

The silent downgrade has caused some confusion in the past and continues to do so. See https://github.com/spring-io/initializr/issues/739, for example. We should consider making the downgrade clearer to the user. One solution was originally being tracked in https://github.com/spring-io/initializr/issues/773 until it was repurposed.

There are two mains approaches that have been thought of thus far:

  1. Update the UI to prevent combinations that would result in a downgrade
  2. Add a note in the HELP.md file that explains what has happened and why

We may even need a hybrid of the two as the first solution won't help for projects generated using a client other than the web UI.

snicoll commented 5 years ago

Blocked on https://github.com/spring-io/initializr/issues/1005 (and having https://github.com/spring-io/initializr/issues/1006 would be useful).

snicoll commented 4 years ago

@wilkinsona I've added a basic note but I can't say for sure what the reason was for the downgrade at the moment as the two things are completely separate. This makes me question if we shouldn't structure things a little bit differently. If the thing that does the action could also add a note, we would have full context when adding it. There might be other side effects though.

wilkinsona commented 4 years ago

Thanks.

If the thing that does the action could also add a note, we would have full context when adding it.

I like the sound of that.

snicoll commented 4 years ago

We discussed this some more. The problem with making that step more smart is that it would require ProjectDescriptionCustomizer to know about HelpDocument. Not only this is a totally separate concept (and should probably remain that way) but customizers are invoked before the ProjectGenerationContext is refreshed.

What we need is a signal that a property of the description was changed and why it was changed. If we had such (independent) information, A HelpDocumentCustomizer could then inject that and generate the appropriate warnings. This would certainly revisit the current diff arrangement we have at the moment.

KotlinIsland commented 1 year ago

Update the UI to prevent combinations that would result in a downgrade

This sounds like the best option. Having completely incompatible options available doesn't make much sense to me.