[
https://issues.jboss.org/browse/JBIDE-16765?page=com.atlassian.jira.plugi...
]
Rob Stryker commented on JBIDE-16765:
-------------------------------------
NickBoldt asked the following about this PR: "why not true.equals() ?"
I am allowing for the possibility that, one day, values other than "true" or
"false" are allowed here. I know this is pretty unlikely, but, if we ever allow
values other than true or false (perhaps listing specific authentication methods), then a
"true" value or a "jdfAuth" or "downloadMgr" value should
fall back to the behavior of NOT downloading, while a null value or a false value can
allow the download to proceed.
Again, I know this is very very unlikely, but, better safe than sorry, and since it's
only 1 line of code, I think it's definitely worth it.
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