Rafael (and others): So I spent an hour or so yesterday chatting with David Hladky about the new download manager rest services which JBosstools intends to use to help us download EAP 6.x. It allows for a workflow that can help us get terms and conditions, verify credentials, verify agreements have been signed, and then provide a download utility with a temporary url that expires to download the EAP. The api and the test server I played with look good so far. JBossTools, though, pulls all of its runtime information from jdf-stacks. We typically pull our download urls from there. Currently in stacks, community editions have a "url" for the project page, and a "downloadUrl" for a link to a permanent url for the given runtime to download. EAP instances in stacks.yaml only have a url for a project page. When the download manager written by David goes live, we'll need to consider what to do for stacks.yaml, and I'd prefer to get this stuff sorted now. I'd like to suggest that we add a new attribute "downloadManagerUrl". This will ensure clients know that this is a workflow url and not a static url for downloading a file. There's 2 parts to the rest service written by David. First is the rest service url itself, and the second is the file we're requesting. Currently a url for one part of the rest workflow (in this example, to get terms and conditions) looks like this: ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar You can see the two parts are the rest service url (on test server, https://www-eng.jboss.org/download-manager/rest/tc) and the second part is what we're requesting (in this case, /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar) I see a few problems here. The first is that, in my opinion, those urls are pretty long to be including in stacks.yaml... but luckily the download-manager allows for shortened urls, so we could have the download-manager server respond to a url like ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. The download manager would then map the attribute to the /content/blah/blah/sha path and proceed accordingly. So this is easily fixed. The second, is that the rest services do not point to the next url to request. For example, if I go to the tc-accepted rest service to see if the terms and conditions were accepted yet, it does not point me to the next url in the workflow. Because of this, there's really no single entry-point in the workflow, and each rest service url is kind of a standalone url. With the second point in mind, we might just want our stacks.yaml attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. The client (in this case jbosstools) would pass that string to the download manager rest service it chooses to use. The download-manager server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more specific /content/sha256/23423823423/etc path, and proceed normally. One concern with this approach is that the stacks.yaml will never include the actual url of the rest service entry point. Even if we wanted to have stacks.yaml point to the entry point, there's no one entry-point since the rest services do not point to the next step in the workflow. I personally have no problem using the service as it's written now, and with stacks.yaml only having a shortened path available, but I wanted to get your (and others) feedback on the situation before this gets pushed to production, after which we probably won't have much chance to change it. Any thoughts? - Rob Stryker

> > will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do. > > David Hladky Yes, David, we will definitely be using that part of the interface. Considering that the download-manager is set to be released and in production soon, I'm really not sure I can expect your team to make changes to the workflow,

responses, etc. I think at this point it's more likely to break stuff. But I'll list the problems so far: 1) Each rest entry point response does not point to the next step in the workflow 2) This means a client (like jbt) must assume the workflow 3) This means that if you guys need to add steps to the workflow in the future, you can't, without breaking clients 4) It also means that we must hard-code each url (tc, tc-accepted, tc-accept, file) and that these become API and can never be renamed. 5) Even if you added the next url as part of the response, your initial entry point is basically the service "tc-accepted", which seems a strange name to begin the workflow. The only part of this I see as 'dangerous' really is item 3) and 4). You guys won't be able to add steps to the workflow without breaking clients. Item 1) is annoying, though, as it means we can't simply put the url to the download-manager with its attribute in stacks.yaml. Considering time is tight and I doubt the download-manager team can make the changes above, For stacks.yaml, I like Rafael's suggestion: downloadUrl=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar

JBT would then recognize the prefix, chop it off, and use that string as what we pass to download-manager's rest services.

Perhaps stacks can have a property somewhere in its client jar that lists the download manager's root url, to avoid multiple clients having it hard-coded everywhere. (Rafael, if you think it doesn't belong there, I guess jbt can just have it hard-coded or pulled from somewhere, but I think if stacks is listing download-manager urls in the stacks.yaml, it should list the URL of the rest services somewhere, for example inside jdf-stacks-client / src / main / resources / org / jboss / jdf / stacks / client / config.properties where you list the stacks url and pre-stacks url) Assuming Rafael's solution doesn't offend anyone, I think it's the best we have for now. > > ----- Original Message ----- > From: "Rob Stryker" <rstryker(a)redhat.com&gt; > To: "David Hladky" <dhladky(a)redhat.com&gt;, "Rafael Benevides" <benevides(a)redhat.com&gt;, "Snjezana Peco" <snjezana.peco(a)redhat.com&gt;, "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)lists.jboss.org&gt; > Sent: Friday, 21 February, 2014 9:24:13 AM > Subject: $0 subscription downloads - Stacks integration with download manager > > Rafael (and others): > > So I spent an hour or so yesterday chatting with David Hladky about the > new download manager rest services which JBosstools intends to use to > help us download EAP 6.x. It allows for a workflow that can help us get > terms and conditions, verify credentials, verify agreements have been > signed, and then provide a download utility with a temporary url that > expires to download the EAP. > > The api and the test server I played with look good so far. JBossTools, > though, pulls all of its runtime information from jdf-stacks. We > typically pull our download urls from there. > > Currently in stacks, community editions have a "url" for the project > page, and a "downloadUrl" for a link to a permanent url for the given > runtime to download. > > EAP instances in stacks.yaml only have a url for a project page. When > the download manager written by David goes live, we'll need to consider > what to do for stacks.yaml, and I'd prefer to get this stuff sorted now. > > I'd like to suggest that we add a new attribute "downloadManagerUrl". > This will ensure clients know that this is a workflow url and not a > static url for downloading a file. > > There's 2 parts to the rest service written by David. First is the rest > service url itself, and the second is the file we're requesting. > Currently a url for one part of the rest workflow (in this example, to > get terms and conditions) looks like this: > > ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar > > You can see the two parts are the rest service url (on test server, > https://www-eng.jboss.org/download-manager/rest/tc) and the second part > is what we're requesting (in this case, > /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar) > > I see a few problems here. The first is that, in my opinion, those urls > are pretty long to be including in stacks.yaml... but luckily the > download-manager allows for shortened urls, so we could have the > download-manager server respond to a url like > ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. > The download manager would then map the attribute to the > /content/blah/blah/sha path and proceed accordingly. So this is easily > fixed. > > > The second, is that the rest services do not point to the next url to > request. For example, if I go to the tc-accepted rest service to see if > the terms and conditions were accepted yet, it does not point me to the > next url in the workflow. Because of this, there's really no single > entry-point in the workflow, and each rest service url is kind of a > standalone url. > > With the second point in mind, we might just want our stacks.yaml > attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. > > The client (in this case jbosstools) would pass that string to the > download manager rest service it chooses to use. The download-manager > server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more > specific /content/sha256/23423823423/etc path, and proceed normally. > > One concern with this approach is that the stacks.yaml will never > include the actual url of the rest service entry point. Even if we > wanted to have stacks.yaml point to the entry point, there's no one > entry-point since the rest services do not point to the next step in the > workflow. > > I personally have no problem using the service as it's written now, and > with stacks.yaml only having a shortened path available, but I wanted to > get your (and others) feedback on the situation before this gets pushed > to production, after which we probably won't have much chance to change it. > > Any thoughts? > > - Rob Stryker _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 02/21/2014 10:41 PM, David Hladky wrote: > Hi Rob, > > will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do. > > David Hladky Yes, David, we will definitely be using that part of the interface. Considering that the download-manager is set to be released and in production soon, I'm really not sure I can expect your team to make changes to the workflow, responses, etc. I think at this point it's more likely to break stuff. But I'll list the problems so far: 1) Each rest entry point response does not point to the next step in the workflow 2) This means a client (like jbt) must assume the workflow 3) This means that if you guys need to add steps to the workflow in the future, you can't, without breaking clients 4) It also means that we must hard-code each url (tc, tc-accepted, tc-accept, file) and that these become API and can never be renamed. 5) Even if you added the next url as part of the response, your initial entry point is basically the service "tc-accepted", which seems a strange name to begin the workflow. The only part of this I see as 'dangerous' really is item 3) and 4). You guys won't be able to add steps to the workflow without breaking clients. Item 1) is annoying, though, as it means we can't simply put the url to the download-manager with its attribute in stacks.yaml. Considering time is tight and I doubt the download-manager team can make the changes above, For stacks.yaml, I like Rafael's suggestion: *downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar JBT would then recognize the prefix, chop it off, and use that string as what we pass to download-manager's rest services. Perhaps stacks can have a property somewhere in its client jar that lists the download manager's root url, to avoid multiple clients having it hard-coded everywhere. (Rafael, if you think it doesn't belong there, I guess jbt can just have it hard-coded or pulled from somewhere, but I think if stacks is listing download-manager urls in the stacks.yaml, it should list the URL of the rest services somewhere, for example inside jdf-stacks-client / src / main / resources / org / jboss / jdf / stacks / client / config.properties where you list the stacks url and pre-stacks url) Assuming Rafael's solution doesn't offend anyone, I think it's the best we have for now. > ----- Original Message ----- > From: "Rob Stryker&quot;&lt;rstryker(a)redhat.com&gt; > To: "David Hladky&quot;&lt;dhladky(a)redhat.com&gt;, "Rafael Benevides&quot;&lt;benevides(a)redhat.com&gt;, "Snjezana Peco&quot;&lt;snjezana.peco(a)redhat.com&gt;, "jbosstools-dev jbosstools-dev&quot;&lt;jbosstools-dev(a)lists.jboss.org&gt; > Sent: Friday, 21 February, 2014 9:24:13 AM > Subject: $0 subscription downloads - Stacks integration with download manager > > Rafael (and others): > > So I spent an hour or so yesterday chatting with David Hladky about the > new download manager rest services which JBosstools intends to use to > help us download EAP 6.x. It allows for a workflow that can help us get > terms and conditions, verify credentials, verify agreements have been > signed, and then provide a download utility with a temporary url that > expires to download the EAP. > > The api and the test server I played with look good so far. JBossTools, > though, pulls all of its runtime information from jdf-stacks. We > typically pull our download urls from there. > > Currently in stacks, community editions have a "url" for the project > page, and a "downloadUrl" for a link to a permanent url for the given > runtime to download. > > EAP instances in stacks.yaml only have a url for a project page. When > the download manager written by David goes live, we'll need to consider > what to do for stacks.yaml, and I'd prefer to get this stuff sorted now. > > I'd like to suggest that we add a new attribute "downloadManagerUrl". > This will ensure clients know that this is a workflow url and not a > static url for downloading a file. > > There's 2 parts to the rest service written by David. First is the rest > service url itself, and the second is the file we're requesting. > Currently a url for one part of the rest workflow (in this example, to > get terms and conditions) looks like this: > > ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar > > You can see the two parts are the rest service url (on test server, > https://www-eng.jboss.org/download-manager/rest/tc) and the second part > is what we're requesting (in this case, > /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar) > > I see a few problems here. The first is that, in my opinion, those urls > are pretty long to be including in stacks.yaml... but luckily the > download-manager allows for shortened urls, so we could have the > download-manager server respond to a url like > ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. > The download manager would then map the attribute to the > /content/blah/blah/sha path and proceed accordingly. So this is easily > fixed. > > > The second, is that the rest services do not point to the next url to > request. For example, if I go to the tc-accepted rest service to see if > the terms and conditions were accepted yet, it does not point me to the > next url in the workflow. Because of this, there's really no single > entry-point in the workflow, and each rest service url is kind of a > standalone url. > > With the second point in mind, we might just want our stacks.yaml > attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. > > The client (in this case jbosstools) would pass that string to the > download manager rest service it chooses to use. The download-manager > server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more > specific /content/sha256/23423823423/etc path, and proceed normally. > > One concern with this approach is that the stacks.yaml will never > include the actual url of the rest service entry point. Even if we > wanted to have stacks.yaml point to the entry point, there's no one > entry-point since the rest services do not point to the next step in the > workflow. > > I personally have no problem using the service as it's written now, and > with stacks.yaml only having a shortened path available, but I wanted to > get your (and others) feedback on the situation before this gets pushed > to production, after which we probably won't have much chance to change it. > > Any thoughts? > > - Rob Stryker _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev