[
https://issues.jboss.org/browse/JBIDE-16765?page=com.atlassian.jira.plugi...
]
Martin Malina commented on JBIDE-16765:
---------------------------------------
I verified a couple of scenarios here:
1. Previous build of JBDS (without this fix) will show the rest url with the new
stacks.yaml and will then fail to download the zip.
2. JBDS 7.1.1.CR1c B688 with prod version of stacks.yaml will continue to work as it used
to.
3. JBDS 7.1.1.CR1c B688 with new version of stacks.yaml will continue to work - the rest
url for EAP 6.x will not be shown, so the result will be exactly the same functionality as
it used to be - manual download will be required in such case.
However, I will wait for [~rrabara] to double check before closing this. (Later today.)
JBDS 7x Download Runtimes backwards compat patch
------------------------------------------------
Key: JBIDE-16765
URL:
https://issues.jboss.org/browse/JBIDE-16765
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: runtime-detection, server
Affects Versions: 4.2.0.CR1
Reporter: Rob Stryker
Assignee: Rob Stryker
Priority: Critical
Labels: respin-c
Fix For: 4.1.2.CR1
Nick has indicated we may be able to get a patch into 7.x if we move very fast. The
question now becomes, what kind of patch do we want?
Here are the patch types I can make to attempt to ensure no breakage:
1) The "Hide-It" Patch - do NOT show a download-runtime object if
requiresCredentials label is set to any value other than false.
2) The "No-Obvious-Change" patch - if requiresCredentials is set, pretend this
downloadRuntime has no downloadUrl (so it continues to behave as it does today, showing a
wizard page with a hyperlink to the project page for use by web browser)
3) The "I-Want-It-All" patch - see if git cherry-pick works and we can move the
entire new functionality over without a breakage. (OH SO RISQUÉ)
These are our three choices. I vote for 1) or 2). I think 3) is very risky since we
haven't even had time to fully test in master. We should avoid 3).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira