Open BarDweller opened 4 years ago
Closing the issue with the assumption Issue 299 contains the fix.
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.
@BarDweller - Any idea when the fix will be available?
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.
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:
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):
If applicable please specify:
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