Most guides now have a pre-defined link to start.spring.io that let users get started in their own environment (rather than having to clone and get initial as the source.
Unfortunately, there are quite a number of inconsistencies and no easy way to figure it out:
- Packages did not match: the generated link uses the content of the field
com.example.accessing-data-cassandra which will generate a package where hypens are replaced by underscore. But the guides do not use that pattern, rather they use accessingdatacassandra. I've fixed quite a lot of links to use that format.
- Build files did not match. Reviewing initial, some dependencies were added, but the link wasn't updated.
- Nit in formatting or structure of the project that may confuse newcomers
It isn't as easy as it sounds though. Some initial project will fail and that's intended because some information is missing that the guide is providing. For those, some tuning is required right now because CI builds initial but I wonder if that's really something we should be doing. Initial failing when it should is fine, IMO, as it is the state you get from start.spring.io.
I wonder if that bit should be removed and replaced by a job that creates a project from start.spring.io with the link and "diff" it with what initial contains. When a difference is found it can be collected for review. Doing so relies on the fact that start.spring.io generates idiomatic projects and we can then remove the CI build on initial.
Most guides now have a pre-defined link to start.spring.io that let users get started in their own environment (rather than having to clone and get
initialas the source.Unfortunately, there are quite a number of inconsistencies and no easy way to figure it out:
com.example.accessing-data-cassandrawhich will generate a package where hypens are replaced by underscore. But the guides do not use that pattern, rather they useaccessingdatacassandra. I've fixed quite a lot of links to use that format.It isn't as easy as it sounds though. Some
initialproject will fail and that's intended because some information is missing that the guide is providing. For those, some tuning is required right now because CI builds initial but I wonder if that's really something we should be doing. Initial failing when it should is fine, IMO, as it is the state you get from start.spring.io.I wonder if that bit should be removed and replaced by a job that creates a project from start.spring.io with the link and "diff" it with what initial contains. When a difference is found it can be collected for review. Doing so relies on the fact that start.spring.io generates idiomatic projects and we can then remove the CI build on initial.