Add an entry to HELP.md that explains the transformation applied to an illegal package name to make it legal

[wimdeblauwe]

If I use dashes in my artifact name (e.g. thymeleaf-live-reload) and I expand the "Options", it shows something like com.company.thymeleaf-live-reload as 'Package Name', which is not a valid package name. Luckily, the generated package name is com.company.thymeleaflivereload so you get a correct package name. It would be good to also have it correct on the website itself.

[wilkinsona]

As things stand this is intentional. The rules are applied on the server-side to ensure consistent behaviour between all of the different clients (web UI, IDEs, Spring Boot CLI, curl/httpie). While the rules could be duplicated in the Web UI there are a couple of notable downsides that we have chosen to avoid by keeping everything server-side-only:

1. There is a risk that the client-side rules and the server-side rules would get out of sync.
2. The rules cannot be applied on the client-side consistently. They can't be applied at all with curl and httpie and the others are either not within our control or they have very different release cycles to start.spring.io.

There are other places where this sort of server-side modification occurs. For example when the version of Java is downgraded. Our current plan for that is to add something to the HELP.md file that explains why that has happened. While the package name isn't exactly the same, I am leaning towards doing nothing at all or taking a similar approach rather than trying to duplicate the rules.

Let's see what the rest of the team thinks.

[wilkinsona]

We discussed this today and the team is in agreement that we should not try to replicate the server-side rules on the client-side. We'll use this issue to track adding an explanation to the generated HELP.md file.

[wimdeblauwe]

I am totally ok with that, just wanted to point out the fact that most people need to do that when writing a client application in order to provide early feedback to their users. Even in a Spring application itself: there are validations done on the database level (e.g. with JPA annotations), but usually, there is also validation done at the (rest)controller level.

The way I usually see it is that server-side validation is the last line of defence and client-side is just "helping" the user as much as possible. So even if not all server side rules are duplicated, it does not matter too much IMO.

But again, not trying to convince you here, just my 2 cents.

[snicoll]

Blocked by spring-io/initializr#1005

[snicoll]

We've made great progress on spring-io/initializr#1023. Unfortunately, the cleaning of the package name happens too soon for us to track it. It's now also blocked by spring-io/initializr#1045