Description of problem: Depending on how you unzip the soa archive, the results are not deterministic. In one method, I end up with an installation where bin/product.conf has contents "slot=soa", however, with another method, I end up with an installation where bin/product.conf has contents "slot=eap" Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. mkdir tmp && mv soa-6.0.0.Alpha-redhat-1-full.zip tmp/ && cd tmp 2. unzip soa-6.0.0.Alpha-redhat-1-full.zip, select "overwrite all" if prompted 3. check bin/product.conf contents, assert contents are "slot=soa" 4. Delete the unzipped folder 5. unzip soa-6.0.0.Alpha-redhat-1-full.zip, select "No to all" if prompted 6. check bin/product.conf contents, assert contents are "slot=eap" (This should not be eap, but it is) 7. Delete the unzipped folder 8. echo soa-6.0.0.Alpha-redhat-1-full.zip | awk '{ print "unzip " $0;}' | sh 9. check bin/product.conf contents, assert contents are "slot=eap" (This should not be eap, but it is) Additional info: This bug may catch anyone who deals with a decent number of runtimes and has decided to use a script to unzip batches of them at a time. It may also catch confused users who are not used to a new zip asking to overwrite files and may select "No to all" assuming something is broken. An unzip command asking to overwrite is very confusing for a user.
Workaround is to use unzip -o flag in a script, or, of course, to always overwrite when prompted.
The zip file is a temporary measure until we have the SOA installer. It is present in the alpha releases and should be replaced for the beta release.
We will be delivering two artifacts for SOA - a zip of EAP+SOA, configured to defaults - an installer containing SY + RTGov (client and server) In addition there will be separate DTGov artifacts - EAP+S-RAMP (with disabled deployment scanner) - S-RAMP installer
We are no longer delivering a zip file as there are too many configurations during installation.