[JBoss JIRA] (JBIDE-21326) Server Adapter: Publishing is not telling me what it's doing
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21326?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21326:
-----------------------------------------------
Also, we can pass to RSync the available instance of IProgressMonitor and notify it of subtasks for each Pod and each IRSyncable processed (creating SubProgressMonitor may be advisable). IRSyncable might provide a human friendly label to be shown in the progress monitor (getName() returns name of implementation class, maybe label shoud be a truncated version of command with some of options). If IRSyncable will accept a listener to the command output, the output partly also can be used to modify text of the current task in progress monitor. The console may also be implemented, though I would recommend a preference that would allow user to choose if he wants it or may get along with an informative progress monitor.
> Server Adapter: Publishing is not telling me what it's doing
> ------------------------------------------------------------
>
> Key: JBIDE-21326
> URL: https://issues.jboss.org/browse/JBIDE-21326
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Andre Dietisheim
> Labels: openshift_v3, server_adapter
> Fix For: 4.3.1.Beta2
>
>
> Currently we dont tell the user what we're syncing up to the pod. We should open up a console that shows the (std) output of the "oc rsync" cmd that we're running behind the scenes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-20331) install grinder fails if blocked by Firefox
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20331?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-20331:
-------------------------------
Attachment: install-grinder-bad-firefox.jpeg
* build 3812 on dev85 - http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
* build 3814 on dev59 - [^install-grinder-bad-firefox.jpeg] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
* build 3814 on dev88 - http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
* build 3817 on dev112 - http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
> install grinder fails if blocked by Firefox
> -------------------------------------------
>
> Key: JBIDE-20331
> URL: https://issues.jboss.org/browse/JBIDE-20331
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.x, 4.4.0.Alpha1
>
> Attachments: build-history.png, ff-profile-manager.png, install-grinder-bad-firefox.jpeg, install-grinder-fail.txt, install-grinder-firefox-problem-testInstall(org.jboss.tools.tests.installation.InstallTest).jpeg, new-firefox-block-UI_dev112.png, new-firefox-block-UI_dev59.png, virt1-ftl.png, virt2-ftl.png
>
>
> {code:title=http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-install-grinder.install-tests.matrix_master/PROJECT=jbosstools,eclipseBundleVersion=mars.R,jdk=jdk1.8,label_exp=%28RHEL6||RHEL7||beaker||jboss-prod%29&&%28x86||x86_64%29/3157/consoleFull}
> 08:02:18 java.lang.RuntimeException: Unable to aquire PluginConverter service during generation for: /mnt/hudson_workspace/workspace/jbosstools-install-grinder.install-tests.matrix_master/d6768101/eclipse/plugins/org.eclipse.oomph.base_1.1.0.v20150609-0914.jar{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21381) Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21381?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21381:
------------------------------------
There's also a bucket of beaker slaves [7], which are a mix of RHEL6 [8] and 7 [9], with a few ppc slaves [10] and one that's only a "beaker" slave with no additional qualifiers [11.
[7] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker/ (30 enabled, 9 disabled)
[8] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker&&RHEL6/ (12 enabled, 4 disabled)
[9] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker&&EAP-RHEL7/ (14 enabled, 2 disabled)
[10] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker&&ppc64/ (4 enabled, 2 disabled)
[11] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/computer/brms06-rhel6-x86...
So, I think for component & aggregate builds on RHEL6/7 we want something like this, including the beaker slaves:
* (RHEL7-ipv6||brms-rhel7-x86-64||beaker-fsw-rhel7||EAP-RHEL7||RHEL6||jboss-prod||beaker)&&!ia64&&!ppc64&&!rhts = http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL7-ipv6||brms...
And for more restrictive jobs like the install jobs, we want something like this, excluding the beaker slaves:
* (RHEL7-ipv6||brms-rhel7-x86-64||beaker-fsw-rhel7||EAP-RHEL7||RHEL6||jboss-prod)&&!beaker&&!ia64&&!ppc64&&!rhts = http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL7-ipv6||brms...
> Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
> --------------------------------------------------------------
>
> Key: JBIDE-21381
> URL: https://issues.jboss.org/browse/JBIDE-21381
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> We currently use an *<assignedNode>* or *label_exp* like this for most of our jobs:
> * (RHEL6||RHEL7||jboss-prod)&&!ia64&&!rhts
> * (RHEL6||jboss-prod)&&!ia64&&!ppc64&&!rhts
> * (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64)
> However, there are currently no slaves in the RHEL7 label [0], so this query really just means RHEL6||jboss-prod.
> [0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7/
> But, since the jboss-prod slaves do NOT have x86 or x86_64 labels, using jboss-prod&&(x86||x86_64) also means ZERO slaves [1].
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28jboss-prod%29&&%...
> Therefore (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64) == RHEL6&&(x86||x86_64) == RHEL6.
> And, jboss-prod only includes RHEL6 slaves [2]:
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/jboss-prod/
> Here's a label query which actually includes some RHEL7 slaves, from the RHEL7-ipv6 bucket of THREE slaves [3]:
> [3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7-ipv6/
> Note too that there are no longer any rhts slaves [4], but there are still some ia64 [5] and ppc64 [6] slaves:
> [4] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/rhts/
> [5] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ia64/
> [6] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ppc64/
> So... if we want a pool of >60 of RHEL6||jboss-prod and also RHEL7-ipv6 (all three of them), we can use these slaves from *(RHEL6||RHEL7-ipv6||jboss-prod)*:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||RHEL7-ipv...
> There are also some unshared RHEL7 slaves we can use:
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64/ (5 disabled)
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker-fsw-rhel7/ (4 disabled)
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/EAP-RHEL7/ (14 enabled, 2 disabled)
> So, here's the combined RHEL7 label:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64||... (17 enabled, 11 disabled)
> And the combined RHEL6 label:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||jboss-pro... (60 enabled, 4 disabled)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21381) Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21381?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-21381:
-------------------------------
Description:
We currently use an *<assignedNode>* or *label_exp* like this for most of our jobs:
* (RHEL6||RHEL7||jboss-prod)&&!ia64&&!rhts
* (RHEL6||jboss-prod)&&!ia64&&!ppc64&&!rhts
* (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64)
However, there are currently no slaves in the RHEL7 label [0], so this query really just means RHEL6||jboss-prod.
[0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7/
But, since the jboss-prod slaves do NOT have x86 or x86_64 labels, using jboss-prod&&(x86||x86_64) also means ZERO slaves [1].
[1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28jboss-prod%29&&%...
Therefore (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64) == RHEL6&&(x86||x86_64) == RHEL6.
And, jboss-prod only includes RHEL6 slaves [2]:
[2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/jboss-prod/
Here's a label query which actually includes some RHEL7 slaves, from the RHEL7-ipv6 bucket of THREE slaves [3]:
[3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7-ipv6/
Note too that there are no longer any rhts slaves [4], but there are still some ia64 [5] and ppc64 [6] slaves:
[4] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/rhts/
[5] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ia64/
[6] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ppc64/
So... if we want a pool of >60 of RHEL6||jboss-prod and also RHEL7-ipv6 (all three of them), we can use these slaves from *(RHEL6||RHEL7-ipv6||jboss-prod)*:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||RHEL7-ipv...
There are also some unshared RHEL7 slaves we can use:
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64/ (5 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker-fsw-rhel7/ (4 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/EAP-RHEL7/ (14 enabled, 2 disabled)
So, here's the combined RHEL7 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64||... (17 enabled, 11 disabled)
And the combined RHEL6 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||jboss-pro... (60 enabled, 4 disabled)
was:
We currently use a query like this for most of our jobs:
* (RHEL6||RHEL7||jboss-prod)&&!ia64&&!rhts
* (RHEL6||jboss-prod)&&!ia64&&!ppc64&&!rhts
* (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64)
However, there are currently no slaves in the RHEL7 label [0], so this query really just means RHEL6||jboss-prod.
[0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7/
But, since the jboss-prod slaves do NOT have x86 or x86_64 labels, so using jboss-prod&&(x86||x86_64) means ZERO slaves [1].
[1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28jboss-prod%29&&%...
Therefore (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64) == RHEL6&&(x86||x86_64) == RHEL6.
And, jboss-prod only includes RHEL6 slaves [2]:
[2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/jboss-prod/
Here's a label query which actually includes some RHEL7 slaves, from the RHEL7-ipv6 bucket of THREE slaves [3]:
[3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7-ipv6/
Note too that there are no longer any rhts slaves [4], but there are still some ia64 [5] and ppc64 [6] slaves:
[4] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/rhts/
[5] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ia64/
[6] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ppc64/
So... if we want a pool of >60 of RHEL6||jboss-prod and also RHEL7-ipv6 (all three of them), we can use these slaves from *(RHEL6||RHEL7-ipv6||jboss-prod)*:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||RHEL7-ipv...
There are also some unshared RHEL7 slaves we can use:
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64/ (5 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker-fsw-rhel7/ (4 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/EAP-RHEL7/ (14 enabled, 2 disabled)
So, here's the combined RHEL7 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64||... (17 enabled, 11 disabled)
And the combined RHEL6 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||jboss-pro... (60 enabled, 4 disabled)
> Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
> --------------------------------------------------------------
>
> Key: JBIDE-21381
> URL: https://issues.jboss.org/browse/JBIDE-21381
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> We currently use an *<assignedNode>* or *label_exp* like this for most of our jobs:
> * (RHEL6||RHEL7||jboss-prod)&&!ia64&&!rhts
> * (RHEL6||jboss-prod)&&!ia64&&!ppc64&&!rhts
> * (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64)
> However, there are currently no slaves in the RHEL7 label [0], so this query really just means RHEL6||jboss-prod.
> [0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7/
> But, since the jboss-prod slaves do NOT have x86 or x86_64 labels, using jboss-prod&&(x86||x86_64) also means ZERO slaves [1].
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28jboss-prod%29&&%...
> Therefore (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64) == RHEL6&&(x86||x86_64) == RHEL6.
> And, jboss-prod only includes RHEL6 slaves [2]:
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/jboss-prod/
> Here's a label query which actually includes some RHEL7 slaves, from the RHEL7-ipv6 bucket of THREE slaves [3]:
> [3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7-ipv6/
> Note too that there are no longer any rhts slaves [4], but there are still some ia64 [5] and ppc64 [6] slaves:
> [4] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/rhts/
> [5] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ia64/
> [6] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ppc64/
> So... if we want a pool of >60 of RHEL6||jboss-prod and also RHEL7-ipv6 (all three of them), we can use these slaves from *(RHEL6||RHEL7-ipv6||jboss-prod)*:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||RHEL7-ipv...
> There are also some unshared RHEL7 slaves we can use:
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64/ (5 disabled)
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker-fsw-rhel7/ (4 disabled)
> * http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/EAP-RHEL7/ (14 enabled, 2 disabled)
> So, here's the combined RHEL7 label:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64||... (17 enabled, 11 disabled)
> And the combined RHEL6 label:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||jboss-pro... (60 enabled, 4 disabled)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21381) Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-21381:
----------------------------------
Summary: Ensure JBT/JBDS are building on RHEL 7 slaves where applicable
Key: JBIDE-21381
URL: https://issues.jboss.org/browse/JBIDE-21381
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build
Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1
Reporter: Nick Boldt
Assignee: Nick Boldt
We currently use a query like this for most of our jobs:
* (RHEL6||RHEL7||jboss-prod)&&!ia64&&!rhts
* (RHEL6||jboss-prod)&&!ia64&&!ppc64&&!rhts
* (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64)
However, there are currently no slaves in the RHEL7 label [0], so this query really just means RHEL6||jboss-prod.
[0] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7/
But, since the jboss-prod slaves do NOT have x86 or x86_64 labels, so using jboss-prod&&(x86||x86_64) means ZERO slaves [1].
[1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28jboss-prod%29&&%...
Therefore (RHEL6||RHEL7||jboss-prod)&&(x86||x86_64) == RHEL6&&(x86||x86_64) == RHEL6.
And, jboss-prod only includes RHEL6 slaves [2]:
[2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/jboss-prod/
Here's a label query which actually includes some RHEL7 slaves, from the RHEL7-ipv6 bucket of THREE slaves [3]:
[3] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/RHEL7-ipv6/
Note too that there are no longer any rhts slaves [4], but there are still some ia64 [5] and ppc64 [6] slaves:
[4] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/rhts/
[5] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ia64/
[6] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/ppc64/
So... if we want a pool of >60 of RHEL6||jboss-prod and also RHEL7-ipv6 (all three of them), we can use these slaves from *(RHEL6||RHEL7-ipv6||jboss-prod)*:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||RHEL7-ipv...
There are also some unshared RHEL7 slaves we can use:
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64/ (5 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/beaker-fsw-rhel7/ (4 disabled)
* http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/EAP-RHEL7/ (14 enabled, 2 disabled)
So, here's the combined RHEL7 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/brms-rhel7-x86-64||... (17 enabled, 11 disabled)
And the combined RHEL6 label:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/label/%28RHEL6||jboss-pro... (60 enabled, 4 disabled)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21233) remove need for a targetplatforms/jbosstoolstarget/neon site
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21233?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21233:
------------------------------------
a) the JBT component, JBT aggregate, & JBDS aggregate sites already build against a SPECIFIC TP, as defined in the parent pom or Jenkins config. The composite sites are also generated using SPECIFIC TPs so we maintain total control over which TP is used at build time. Nothing changes there.
b) we never removed the associate sites for JBT. We only removed it for JBDS. This JIRA is concerned with doing the same thing we did for JBDS now for JBT. That's why I'm surprised you're so concerned about making a change for JBT which we all agreed was a benefit to JBDS.
"Required sites" are the same as "associate sites" as defined in the update site's metadata. We used to use an Ant script (back in 2011) but we ported that to Maven so we can do this:
https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat...
So, no, I'm not forgetting how we used to do things. If you look at the code in the artifacts.xml you'll see the output is the same as it was in 2011.
c) No, this doesn't change anything about BUILDING. This only changes the INSTALL experience for users since we'd only be changing the contents of the composite site they use to do the INSTALL. Re: "p2 required sites", see my answer in (b). We do, and I want to remove that because it's no longer needed.
----
The ONLY benefit having a /targetplatforms/jbosstoolstarget/mars/ composite site provides is to expose a Mars.0 user to a TP with Mars.1 bits so we can encourage them to update to the newer Eclipse / WTP / Egit / m2e / etc.
But since that's ALSO available in http://download.jboss.org/jbosstools/mars/stable/updates/ because that composite includes our Mars.1 TP, the associate site provides no value except to clutter the Available Software Sites preference page. THAT is why I want to remove it: no value and comes with a maintenance cost.
> remove need for a targetplatforms/jbosstoolstarget/neon site
> ------------------------------------------------------------
>
> Key: JBIDE-21233
> URL: https://issues.jboss.org/browse/JBIDE-21233
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, target-platform
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
> Attachments: jbt-creeping-update-sites.png
>
>
> For the last few years, we've had an associate site ref inside the JBT agg site, pointing at "the latest maximum TP", eg., http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/mars/
> But since we now always co-release JBT with its TP in the same URL, this is only useful for someone who wants to do an OFFLINE install using the zip, which will then go ONLINE to resolve TP dependencies. It's at best a broken use case, and at worst it's unnecessary cruft to maintain.
> Therefore I propose we stop linking to this site.
> We can build the aggregates using a specific TP (the one in the parent pom, natch), and simply NOT use an associate site in the JBT aggregate site build.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21375) Missing label for a filter in OpenShift Explorer
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21375?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21375:
-----------------------------------------------
org.jboss.tools.openshift.ui/plugin.xml in line 22 has
{code}
name="org.jboss.tools.openshift.ui.explorer.navigatorContent"
{code}
Value "org.jboss.tools.openshift.ui.explorer.navigatorContent" is assigned to 'id' attribute in line 20, so that 'name' should be human friendly. [~fbricon], what the nice name may be? - "OpenShift 3 Explorer Content"?
> Missing label for a filter in OpenShift Explorer
> ------------------------------------------------
>
> Key: JBIDE-21375
> URL: https://issues.jboss.org/browse/JBIDE-21375
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Xavier Coulon
> Attachments: Screenshot 2015-12-21 16.26.50.png
>
>
> The list of filters on the OpenShift Explorer view shows 2 entres, but the first one seems to miss a proper label.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-20847) Only "retrieve" and "sign up here" link inside styled text should be accessible
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20847?page=com.atlassian.jira.plugi... ]
Fred Bricon closed JBIDE-20847.
-------------------------------
Resolution: Duplicate Issue
Closing as duplicate of JBIDE-21379 (even though it's technically the other way around)
> Only "retrieve" and "sign up here" link inside styled text should be accessible
> -------------------------------------------------------------------------------
>
> Key: JBIDE-20847
> URL: https://issues.jboss.org/browse/JBIDE-20847
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.CR2
> Reporter: Marián Labuda
> Labels: connection_wizard
> Fix For: 4.3.1.Beta2
>
>
> In New Connection dialog are 2 styled texts with links.
> First one is for OpenShift 2 server selection on top saying "If you do not have an account on OpenShift, please +sign up here+."
> Second one is for OpenShift 3 while OAuth authentication protocol is selected "Enter a token or +retrieve+ a new one."
> Issue is that both are clickable whole, not just the underlined parts.
> Issue is also differences while mouse cursor is moving over them. Second one, about a token, has hand cursor while mouse is over the text. First one has typical cursor for text. The cursor could be:
> - for clickable part hand cursor
> - for nonclickable part arrow cursor
> Example of nice working text with link is link for OpenShift 3 server on top of wizard "New to OpenShift 3? Explore the +getting started documentation+." (Since JBIDE-20849 this link works as the two above.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBIDE-21379) Enhance emulated link
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21379?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21379:
-----------------------------------------------
[~mlabuda], PR to this issue fixes all occurrences of this link, can we close JBIDE-20847 as duplicate of this?
> Enhance emulated link
> ---------------------
>
> Key: JBIDE-21379
> URL: https://issues.jboss.org/browse/JBIDE-21379
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.0.Alpha1
>
>
> Emulated link in 'Sign in to Openshift' wizard 'Deploy Image to OpenShift', etc has several drawbacks:
> 1. It shows hand cursor at the entire text, not only the one styled as link.
> 2. It acts on mouse down, whereas commonly links act on mouse up.
> 3. It acts on clicking at any place in the text, not only the one styled as link.
> 4. If mouse remains down, action is called repeatedly.
> I suggest the enhancement, [~fbricon], please take a look at it. It should be taken into account, that the emulation itself exists because of failure of standard Link on Mac, so that my suggestion should be tested on Mac.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months