$0 subscription downloads - Stacks integration with download manager
by Rob Stryker
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
9 years, 1 month
Change
by Mickael Istria
Hi all,
Here is a proposal for a new 4.32.0.Alpha1-SNAPSHOT target platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/37
It consists in the following changes:
* Move to Kepler SR2
** some projects are still using same version that we had for Kepler release (Orbit, m2eclipse, TM, SWTBot)
** most projects have contributed a SR2 build
Please review this PR and yell if there is anything shocking. You can use the following stuff to try to build build the TP locally and try out against your component.
Once this changed is pushed, CI jobs for branch 4.1.x will be updated to use it as TARGET_PLATFORM_MAXIMUM.
Build target-platform:
$ cd jbosstools-target-platforms
$ git fetch mistria Kepler-SR2
$ git checkout FETCH_HEAD
$ cd jbosstools/multiple
$ mvn clean install -P \!multiple2repo
Try with just built target-platform:
$ cd /path/to/your/component
$ mvn clean verify -Dtpc.version=4.32.0.Alpha1-SNAPSHOT -Pmultiple.target
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9 years, 1 month
JBoss Tools 4.1.2.CR1 codefreeze is next thursday (27th February)
by Nick Boldt
-------- Original Message --------
Subject: JBDS 7.1 CR1 codefreeze is next thursday
Date: Thu, 20 Feb 2014 11:42:00 +0100
From: Max Rydahl Andersen <manderse(a)redhat.com>
To: external-exadel-list(a)redhat.com external-exadel-list(a)redhat.com
<external-exadel-list(a)redhat.com>
Hi,
A friendly reminder that next thursday (27th February) is code freeze
for JBoss Tools 4.1.2 and Developer Studio 7.1.1
We already have some issues done here but please don't forget that when
you or QE find issues in master that affects
maintenance to clone and raise them as issues to consider for
maintenance!
Thanks,
/max
http://about.me/maxandersen
9 years, 1 month
IMPORTANT: Testing in PDE is *never* enough
by Max Rydahl Andersen
Hi team,
The last two blocking issues for Alpha2:
https://issues.jboss.org/browse/JBIDE-16572 and
https://issues.jboss.org/browse/JBIDE-16430
shows that yet again we need to remember that it is *not* sufficient to
test your plugin
in isolation from your perfect development environment.
In this case it was a missing plugin entry in feature.xml and a bug in
Luna M5 that would have been
visible several weeks ago.
Yes, it is human to error and failure is much better than no progress at
all.
But QE should not have to fight so easily avoidable and basic failures
like this.
Please take the time necessary to try out your plugins new feature in
the actually distributed
environment with all plugins installed and we would not have to hustle
so close to the release.
This time combines pretty well together with writing your New and
noteworthy https://issues.jboss.org/browse/JBIDE-16551
which also is part of the code freeze week.
Thanks,
/max
http://about.me/maxandersen
9 years, 1 month
Feedback on JBoss Tools Cordova
by Mickael Istria
Hi all,
I went to see this presentation yesterday
http://humantalks.com/talks/347-demonstration-de-cordova-cli and had the
opportunity to show the demo to 4 people who are actual Cordova users.
The presentation, from Sebastien Paul, was mainly showing simple usage
of Cordova CLI. The demo showed many things that are available in the
Cordova Eclipse plugins as well (create a project, add plugin, start ios
emulator...). The only thing he didn't have in his CLI demo compared to
the video is CordovaSim/Ripple.
He also demoed something nice: a livereload-cordova plugin (
https://github.com/fingerproof/cordova-plugin-gapreload and
https://vimeo.com/81192559 ). This is interesting because it allows to
configure the packaged application (the apk, ios, or whatever actual
package) to use livereload to check for updates of some of its
resources. So you can get livereload enabled on your actual tests
devices while developing a cordova application and see updates without
any need to repackage or redeploy the application. It's IMO a great
productivity boost. Of course, this is something people wouldn't like to
ship as part of there delivery, and is only good for development
purpose. See last paragraph for more thoughts on this topic.
Feedback on JBoss Tools Cordova was quite positive. However, no-one did
even know such tools were existing. Some Cordova users are not at all
aware of what is JBoss and never started an Eclipse, although they'd be
glad to use it for Cordova development as shown in the video. Some said
they'll show the demo to some colleagues who are used to do Android
development, and that they're pretty sure they'll start using Cordova
Tools today.
From this, we can deduce that:
1. Our tools really matches the current needs of users, and that's great
2. Those same tools are unknow to most of potential users. In order to
become famous, it appears we need to communicate about it in
Cordova/Phonegap specific channels (mailing-list, get retweeted by
@apachecordova and @phonegap ).
Related to the concept of having plugins in a dev-mode, we discussed the
idea of "profiles", similar to what Maven does, which would allow to
package application in different flavours: Use this plugin in dev-mode
with this set of properties (for example pointing to local IP address),
whereas production should not ship this plugin and use the production
URL... This would be an interesting feature.
That's all folks.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9 years, 1 month
