My first suggestion should be to use downloadUrl attribute but given
that it's a workflowUrl I'm ok to create a label called
downloadManagerUrl. We can't add an attribute without change the version
(it breaks stacks-client).
I also liked to use a short version
downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. But it lead me
to think If we can do something like:
This way we can continue to use the existing *downloadUrl attribute* but
also emphasizes that this use uses a custom "protocol" that is handled
by the downloadManager
This is my 2 cents.
Em 21/02/14 05:24, Rob Stryker escreveu:
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
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:
You can see the two parts are the rest service url (on test server,
) and the second
part is what we're requesting (in this case,
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
download manager would then map the attribute to the
/content/blah/blah/sha path and proceed accordingly. So this is easily
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
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.
- Rob Stryker