Spring stack requires unique parent pom id.

[BarDweller]

The Spring Boot Stack is mistakenly sharing it's parent pom id with the Appsody stack.

Maven artifacts are expected to have unique coordinates (artifactid/group/version) for any given content. This stack is violating that expectation as the parent pom has the same coordinates as the appsody stack, but has different content.

This means that if the Appsody and Kabanero Spring Boot Stacks are used on the same system, there is potential for the installed parent pom to be overwritten with each others content, actual behavior is undefined, and errors will be expected.

To Reproduce
Steps to reproduce the behavior:

1. appsody init a spring boot project from the kab repo
2. note the parent pom coordinates from the generated project
   2b. examine the parent pom content in the local maven cache
3. appsody init a spring boot project from the appsody repo
4. note the parent pom coordinates from the generated project
   4.b examine the parent pom content in the local maven cache.
5. notice that if steps 2 & 4 gave the same coordinates, that different content cannot exist in the cache at the same location, and which ever parent pom is there is now only correct for one of the projects.

Expected behavior
Parent poms should have unique id's to prevent the clash.

Actual behaviour
Parent pom has same id causing the clash.

Environment Details (please complete the following information):

• OS: doesn't matter
• Browser: irrelevant
• Version: All kab/appsody spring boot stacks (with the exception of the potentially unshipped kab/icpa stacks at 0.3.23)

If applicable please specify:

• CLI version: n/a
• Collection you are using: java-spring-boot2

Additional context

Stack 0.3.23 added -snowdrop to make the parent pom unique, but the implications of doing so were not containable within the timeframe for the 0.6.0 release. This defect is to track the appropriate resolution of those issues
.
This Issue should be targetted at 0.7.0

[marikaj123]

Closing the issue with the assumption Issue 299 contains the fix.

[BarDweller]

Please reopen, 299 is NOT the fix for this, 299 was the revert of the fix for this to prevent regressions, this Issue is to track delivery of the actual fix.

[marikaj123]

@BarDweller - Any idea when the fix will be available?

[BarDweller]

We need to understand how to deliver a breaking change to a collection, and what that entails from a stack deprecation / versioning perspective..

The change itself is trivial, understanding the process required to deliver it.. less so.