Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Edit Starters doesn't properly handle removal of all dependencies #52
When all dependencies are removed/unchecked from a boot project. The edit starters tends to create a broken project because it does not ensure that at leats a dependency like:
Steps to reproduce:
=> The dependency is removed from the pom leaving no dependencies in the pom at all.
The project is now broken and has compile errors.
Expected behavior is that upon removal of the last dependency we ensure that at least a dependency on
The expected behavior is not enough, a corner case is found.
So we still need to add the base starter back if it's the only starter of the project.
I just got a report from another user in slack chat, complaining about other discrepancies between edit starters and what intializer app generates.
Apparantly since this was implemented in STS quite a while ago, the initializer app has gotten a bit more sophisticated and it is not just a 1-1 mapping between a selected checkbox and a dependency. There are also some dependencies that get added as a kind of 'cross selection'. I.e. sometimes extra dependencies will get added as 'extra' when two boxes are selected together.
The example he gave was:
If you instead only selects
I'm not totally sure yet how we can handle this. But admittedly I think it should be thought of as a bug.
I have some idea. Perhaps the 'Edit Starters' should be re-written from scratch so that it doesn't try to decide by itself how to create the edits. Instead, we could use initializr app to create two poms. One for the 'initial' state of the edit starters dialog selection, and then a second one for the edited state. Then we can compute some kind of a diff between the two poms, and then somehow use that diff to update the user's pom. I think this might be a better way, as it wouldn't need to know exactly how the initializer logic works internally. And perhaps it would solve all of these discrepancies at once (though I guess implementing the diffing system might be a little tricky, as I doubdt that simply doing a textual diff will be good enough).
referenced this issue
May 3, 2018
Yes we also noticed the similar scenarios. I think the best way is to have related APIs telling the exact mapping of dependencies. Diffing XML content is also acceptable. But plain textual diff also has some pitalls, e.g. compare the following two BOMs :