[JBoss JIRA] (JBIDE-20141) Define which vanity URLs to use for publishing JBT/JBDS nightlies & dev sites
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20141?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-20141:
---------------------------------------------
when did I see this: we discussed it via irc several times last week.
A) you asked for having ability to browse directory content. I agreed that would be nice, but having a place with nice html page without internal details exposed is nice too. Hence why a composite at /updates/*/mars would be useful.
B) you request in this to have both master and 4.3.mars as url which defeats the whole purpose of having a stable url to use for updates.
Thus no, I do not think i it is useful to expose public urls that changes over time, nor has core nor versions in them when that is not what we will end up using for release.
the updatesite site for nighlty (or snapshots if that is what that makes most sense) nor our development builds should *not* change over the year. They should not be affected by our *internal* build setup of using a branch for building releases.
I don't really know how to make it more clear - we've had this issue *every* year and I keep opening bugs to stop it from happening.
> Define which vanity URLs to use for publishing JBT/JBDS nightlies & dev sites
> -----------------------------------------------------------------------------
>
> Key: JBIDE-20141
> URL: https://issues.jboss.org/browse/JBIDE-20141
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta2
>
>
> Today, we produce a lot of artifacts w/ every CI (snapshot), staging, development, & stable build.
> But sometimes, finding these artifacts can be a daunting task.
> Below are some URLs where things can be found.
> *CI builds / SNAPSHOTS / nightlies*
> * http://download.jboss.org/jbosstools/updates/nightly/master/ -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central, *OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/updates/nightly/mars -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central, *OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/mars/nightly/updates/ -> ../../mars/snapshots/builds/jbosstools-discovery.central_master/latest/all/repo/ (composite of Core + Central)
> * http://download.jboss.org/jbosstools/mars/snapshots/updates/ (individual projects' update sites)
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/core/master/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/webtools/master/
> ** http://download.jboss.org/jbosstools/mars/snapshots/updates/webtools/4.3....
> ** ..
> * http://download.jboss.org/jbosstools/mars/snapshots/builds/ (individual timestamped CI builds)
> *Staging Sites*
> * http://download.jboss.org/jbosstools/mars/staging/builds/
> * http://download.jboss.org/jbosstools/mars/staging/updates/
> *Development Milestones*
> * http://download.jboss.org/jbosstools/updates/development/mars/ -> ../../mars/development/updates/ (*OLD URL PATTERN*)
> * http://download.jboss.org/jbosstools/mars/development/updates/ (composites & content that isn't *static*)
> * http://download.jboss.org/jbosstools/static/mars/development/updates/ (actual update sites, moved here for Akamai performance)
> ----
> For JBDS, we follow the same pattern as above but use https://devstudio.redhat.com/9.0/ instead of http://download.jboss.org/jbosstools/mars/ ... but we also have a /builds/installer/ folder because the public JBDS site now includes the standalone installer:
> * https://devstudio.redhat.com/9.0/development/builds/installer/
> Also, for JBDS we don't have to differentiate between /static/ and non-static content, since Akamai set up the entire server to be mirrored to their servers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-19335) org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeLicenseFragment fails with SWTError without browser available
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19335?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19335:
---------------------------------------------
inconsistent property - all explained in the PR - but putting it here for ref in case you missed it:
{quote}
if it is going to be there then follow the naming pattern/conventions we have elsewhere.
lowercase
"scoped" by package/feature
so that would be something like 'jbosstools.skip.browser.creation' even though I can see it seems in foundation there is already several variations; but lets not make it worse.
and since it is a boolan it should not accept skipBrowserCreation=false
{quote}
mixed license text - you answered "Good catch" on the PR (see https://github.com/jbosstools/jbosstools-base/pull/419#discussion-diff-33...) so sounds like you agreed with me there - what changed ?
no tests - this issue talks about a specific error situation, can that not be tested for ? many plugins now have swtbot tests for several years so can look for that.
> org.jboss.tools.runtime.ui.internal.wizard.DownloadRuntimeLicenseFragment fails with SWTError without browser available
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19335
> URL: https://issues.jboss.org/browse/JBIDE-19335
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: common/jst/core, runtime-detection
> Affects Versions: 4.2.3.Beta1, 4.3.0.Alpha1
> Environment: Linux
> Reporter: Denis Golovin
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta2
>
>
> DownloadRuntimeLicenseFragment should work even without browser widget available and show html or text without html tags with <p> and <br> elements replaced with '\n'.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19757:
---------------------------------------------
Just checked.
JBoss Tools Server Adapter shows up around the 30 second mark - noticeably slower than every other server adapter except Geronimo. I wonder why we are that slow compared to rest - only reason I can see is that we now require alot bigger set of metadata to download.
But it is better it works than it shows up fast and then does not work.
If it was not noticed in past we need to ensure it keeps being noticed in future.
[~rob.stryker], [~mmalina] and [~nickboldt] we have both unit tests, integration tests and p2 install tests - at least the latter two should have caught this. Can you make sure testing from this updatesite gets covered - thanks.
I found JBIDE-20164 while testing, but that is separate.
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Minor
> Labels: releasework
> Fix For: 4.3.0.Beta1
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-20164) webtools server adapter installation shows "null"
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-20164:
-------------------------------------------
Summary: webtools server adapter installation shows "null"
Key: JBIDE-20164
URL: https://issues.jboss.org/browse/JBIDE-20164
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: server
Reporter: Max Rydahl Andersen
When using the "download additional adapters" for JBoss Tools it has a few issues.
a) shows "null" for vendor
b) does not actually say it is for WildFly nor EAP servers
c) (idea) should we add OpenShift to this ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JBIDE-19817) Application wizard: v3 application wizard needs to be able to react to changing connections
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19817?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-19817:
----------------------------------------
Sprint: Sprint #4 May 2015, Sprint #5 Jun 2015, Sprint #6 July 2015 (was: Sprint #4 May 2015, Sprint #5 Jun 2015)
> Application wizard: v3 application wizard needs to be able to react to changing connections
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-19817
> URL: https://issues.jboss.org/browse/JBIDE-19817
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Andre Dietisheim
> Assignee: Jeff Cantrill
> Priority: Blocker
> Labels: openshift_v3
> Fix For: 4.3.0.Beta2
>
>
> The current application wizard for OpenShift v3 takes a project in the constructor. It was designed to be launched from the explorer where a v3 connection/project is selected before the wizard is launched. The wizard is not able to react to changing connections. In order for the wizard to be able to get launched from File->New->OpenShift we need the wizard to be able to react to chaning connections.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months