[jbosstools-issues] [JBoss JIRA] (JBIDE-16765) JBDS 7x Download Runtimes backwards compat patch

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953712#comment-12953712 ] 

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