[jbosstools-issues] [JBoss JIRA] (JBIDE-19948) Reimplement Eclipse Download plugin to allow dynamic work flow

[Rob Stryker (JIRA)]

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

Rob Stryker commented on JBIDE-19948:
-------------------------------------

Hi [~dhladky]:

[~maxandersen] and I have discussed the issue and do not feel a dynamic workflow is something we can make work in the next 2 months. 

Other things I've noticed by reviewing ORG-2414 are:

1) [~pmuir] indicated that the website does not use stacks.yaml

2) stacks.yaml is intended for automated consumption, not human consumption. 

3) stacks.yaml has only a vague label "requiresCredentials" which isn't enough. We could possibly add a credentialType={jboss/redhat/apache/sourceforge/none} label as well, and eventually (2 years later?) deprecate the old requiresCredentials=true. 

4) This would allow our plugin to provide different credentialing implementations and UI based on that flag, which would be useful. We would have to work under the assumption that all existing yaml objects with requiresCredentials=true and no credentialType value would default to the jboss credentialing.   If we went this route, it'd also be easier for us to automatically tack on a ?workflow=direct or ?workflow=rest, since we'd know we're only doing it for those with the proper credentialType.   But, again, as Pete said, it's not necessary at this time to have stacks usable by humans. 

5) If we eventually wanted to change the expected request / response format, I would suggest we start passing protocol version strings back and forth. I would expect the server to continually support previous versions when such a flag is passed in, even if newer versions of the request/response are preferred. 

So for example, we would expect that the existing jdf urls continue to work as they currently do when no protocol version is passed in. This means you would check for a protocol version somehow (passed in as a parameter to the URL or via request header, still some questions here I need to work out). If there is none, you use the current behavior, which means you DO ask for country, but simply put in a "Not Required" option, or delete all options except "NOT REQUIRED".  

If a client *does* pass in a newer protocol version string, you could then provide a request/response protocol that never asks for a country. 

This would also allow you to make unit tests now that guarantee the behavior of existing urls with no protocol version passed in continue to function as they always have and never change. This would also allow you to make changes to the protocol however you wish (such as removing country, or adding new questions) so long as you do so only in a new version of the protocol. 

Then, clients can move up to the newest version at whatever speed they are able to, based on their internal schedules, release cycles, feasible timeframes, etc. 

Basically, the idea of you changing the request/response and us simply reacting 'dynamically' doesn't seem reasonable after some thought. The opportunity for bugs or regressions or breaking behavior is too great, as we've seen in the past 18 months. Having guaranteed protocols that do not change with version strings seems a much more reasonable solution. 

Doing it this way, though, also allows us a lot more flexibility than you'd think. Stacks.yaml would have something like credentialType=jboss.  Our tools would recognize that, and could safely append a ?workflow=rest&version=2  (or request headers) if we wanted, without worrying that we're adding them to an apache or sourceforge download.  And we could update our UI to match the protocol version we're using, without worrying you might change the protocol later. 

Finally, this would allow you to deprecate old protocol versions once you know all supported clients have moved off, rather than trying to get all clients to move or change at the same time. 

> Reimplement Eclipse Download plugin to allow dynamic work flow
> --------------------------------------------------------------
>
>                 Key: JBIDE-19948
>                 URL: https://issues.jboss.org/browse/JBIDE-19948
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: runtime-detection, server
>    Affects Versions: 4.3.0.Alpha2
>            Reporter: David Hladky
>            Assignee: Rob Stryker
>             Fix For: 4.3.0.CR1
>
>
> We need to reimplement the plugin to accept new terms and conditions models as well as follow the workflow changes in case of changes to the current ones. 
> Under this issue I will create the tasks we need to achieve this goal. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)