[JBoss JIRA] (JBIDE-20753) Text flickering when selecting server types in New Server wizard
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20753?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-20753:
---------------------------------------
[~rob.stryker] are you saying you can't reproduce this? Cause it should be trivial.
Here's a screencast: http://screencast.com/t/MVXEn9kjh
As expected, in most cases the video didn't capture the tiny period where this thing appeared, but in a few occasions it's visible.
> Text flickering when selecting server types in New Server wizard
> ----------------------------------------------------------------
>
> Key: JBIDE-20753
> URL: https://issues.jboss.org/browse/JBIDE-20753
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.0.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: regression
> Fix For: 4.3.x, 4.4.0.Alpha1
>
>
> When you open the New Server wizard and select a server type, There will be some elements rendered for a fraction of a second. It's Server Runtime Environment and a dropdown menu - it will disappear again, but it's not nice to see something quickly appear and disappear again. You can keep selecting server types and it will keep happening. All of this is on the first page of the dialog.
> I checked and this did not happen in Beta2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-16970) create p2diff job to verify that nightly build is different from previous milestone
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-16970 at 12/1/15 11:34 AM:
--------------------------------------------------------------
While we could use p2diff (assuming we can get it to run across all the slaves - in the past it had a tendency to hang, so I removed Mickael's prototype on March 12 2015) [1], we can also just diff the buildinfo.json files to compare the latest list of SHAs in order to determine if there are upstream SOURCE changes, and therefore also BINARY changes.
[1] https://github.com/jbdevstudio/jbdevstudio-ci/commit/ad8371734fb1839bce75...
I've added support for diffing ALL the SHAs, not just the first/principal one.
https://github.com/jbosstools/jbosstools-build-ci/commit/cab99f1346fff090... (4.4.x branch)
https://github.com/jbosstools/jbosstools-build-ci/pull/138 (4.3.x branch)
Local tests indicate this works great - I added a *-debug* flag to make it easier to see why the script is returning "true" (SHAs differ) or "false" (SHAs are unchanged).
So I've added the new *-all* flag to the master job [2] config. Building...
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=11138
If successful I need to:
* push the PR
* rebuild build-ci in 4.3.x branch
* add the *-all* flag to all the aggregate jobs (core, coretests, child sites, integration tests) for both 4.4 and 4.3 branches
was (Author: nickboldt):
While we could use p2diff (assuming we can get it to run across all the slaves - in the past it had a tendency to hang, so I removed Mickael's prototype on March 12 2015) [1], we can also just diff the buildinfo.json files to compare the latest list of SHAs in order to determine if there are upstream SOURCE changes, and therefore also BINARY changes.
[1] https://github.com/jbdevstudio/jbdevstudio-ci/commit/ad8371734fb1839bce75...
I've added support for diffing ALL the SHAs, not just the first/principal one.
https://github.com/jbosstools/jbosstools-build-ci/commit/cab99f1346fff090... (4.4.x branch)
https://github.com/jbosstools/jbosstools-build-ci/pull/138 (4.3.x branch)
Local tests indicate this works great - I added a *-debug* flag to make it easier to see why the script is returning "true" (SHAs differ) or "false" (SHAs are unchanged).
So I've added the new *-all* flag to the master job [2] config. Building...
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=11138
> create p2diff job to verify that nightly build is different from previous milestone
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-16970
> URL: https://issues.jboss.org/browse/JBIDE-16970
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> After the discovery site build job is done, we should:
> * get a list of JIRAs for a given target fixversion, eg., 4.2.0.Beta1 or 8.0.0.Beta1 *job param* milestone = Beta1, Beta2, CR1, Final/GA (special case)
> * for respins, use *job param* label = "respin-a" or "respin-b" in jira query
> * filter query to only show the components and map those to actual project names - see https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTaskJ... for mappings
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6
> * install last milestone from *job param* oldURL = http://download.jboss.org/jbosstools/updates/staging/JBossTools-4.2.0.Bet...
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6 (in a different folder)
> * install new nightly from *job param* oldURL = http://download.jboss.org/jbosstools/updates/nightlycore/4.2.luna/
> * compare installed footprints - see https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/instal...
> * run p2diff on the two repos - see https://github.com/irbull/p2diff
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-16970) create p2diff job to verify that nightly build is different from previous milestone
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-16970 at 12/1/15 11:31 AM:
--------------------------------------------------------------
This should also be enabled as a replacement for the skipRevisionCheckWhenPublishing system for aggregate builds, so that before performing a publish, the destination is diffed to the staged folder in Jenkins, to determine if a publish is needed.
Need a different check (compare manifest.mf for eclipse-sourcerefs ?) for determining if a new project build needs to be published.
was (Author: nickboldt):
This should also be enabled as a replacement for the skipRevisionCheckWhenPublishing system for aggregate builds, so that before performing a publish, the destination is diffed to the staged folder in Jenkins, to determine if a publish is needed.
Need a different check (compare manifet.mf for eclipse-sourcerefs ?) for determining if a new project build needs to be published.
> create p2diff job to verify that nightly build is different from previous milestone
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-16970
> URL: https://issues.jboss.org/browse/JBIDE-16970
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> After the discovery site build job is done, we should:
> * get a list of JIRAs for a given target fixversion, eg., 4.2.0.Beta1 or 8.0.0.Beta1 *job param* milestone = Beta1, Beta2, CR1, Final/GA (special case)
> * for respins, use *job param* label = "respin-a" or "respin-b" in jira query
> * filter query to only show the components and map those to actual project names - see https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTaskJ... for mappings
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6
> * install last milestone from *job param* oldURL = http://download.jboss.org/jbosstools/updates/staging/JBossTools-4.2.0.Bet...
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6 (in a different folder)
> * install new nightly from *job param* oldURL = http://download.jboss.org/jbosstools/updates/nightlycore/4.2.luna/
> * compare installed footprints - see https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/instal...
> * run p2diff on the two repos - see https://github.com/irbull/p2diff
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-16970) create p2diff job to verify that nightly build is different from previous milestone
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16970?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-16970:
------------------------------------
While we could use p2diff (assuming we can get it to run across all the slaves - in the past it had a tendency to hang, so I removed Mickael's prototype on March 12 2015) [1], we can also just diff the buildinfo.json files to compare the latest list of SHAs in order to determine if there are upstream SOURCE changes, and therefore also BINARY changes.
[1] https://github.com/jbdevstudio/jbdevstudio-ci/commit/ad8371734fb1839bce75...
I've added support for diffing ALL the SHAs, not just the first/principal one.
https://github.com/jbosstools/jbosstools-build-ci/commit/cab99f1346fff090... (4.4.x branch)
https://github.com/jbosstools/jbosstools-build-ci/pull/138 (4.3.x branch)
Local tests indicate this works great - I added a *-debug* flag to make it easier to see why the script is returning "true" (SHAs differ) or "false" (SHAs are unchanged).
So I've added the new *-all* flag to the master job [2] config. Building...
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=11138
> create p2diff job to verify that nightly build is different from previous milestone
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-16970
> URL: https://issues.jboss.org/browse/JBIDE-16970
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.2.0.Beta1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> After the discovery site build job is done, we should:
> * get a list of JIRAs for a given target fixversion, eg., 4.2.0.Beta1 or 8.0.0.Beta1 *job param* milestone = Beta1, Beta2, CR1, Final/GA (special case)
> * for respins, use *job param* label = "respin-a" or "respin-b" in jira query
> * filter query to only show the components and map those to actual project names - see https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTaskJ... for mappings
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6
> * install last milestone from *job param* oldURL = http://download.jboss.org/jbosstools/updates/staging/JBossTools-4.2.0.Bet...
> * install Eclipse from *job param* eclipseBundleVersion = luna.M6 (in a different folder)
> * install new nightly from *job param* oldURL = http://download.jboss.org/jbosstools/updates/nightlycore/4.2.luna/
> * compare installed footprints - see https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/instal...
> * run p2diff on the two repos - see https://github.com/irbull/p2diff
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21163) cdk server adapter dumps out adbinfo to console
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21163?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-21163:
-----------------------------------
Assignee: Rob Stryker
> cdk server adapter dumps out adbinfo to console
> -----------------------------------------------
>
> Key: JBIDE-21163
> URL: https://issues.jboss.org/browse/JBIDE-21163
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
>
> is it intended that if the cdk is running the console shows up with dump that contains:
> {quote}
> # Set the following environment variables to enable access to the
> # docker daemon running inside of the vagrant virtual machine:
> export DOCKER_HOST=tcp://10.1.2.2:2376
> export DOCKER_CERT_PATH=/Users/max/code/cdk/openshift-vagrant/cdk-v2/.vagrant/machines/default/virtualbox/.docker
> export DOCKER_TLS_VERIFY=1
> export DOCKER_MACHINE_NAME=9dc5acb
> # run following command to configure your shell:
> # eval "$(vagrant adbinfo)"
> {quote}
> it is a bit confusing it pops up with no info and gets to be in front of everything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21164) cdk server adapter shows error then overridden by adbinfo output
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21164?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-21164:
-----------------------------------
Assignee: Rob Stryker
> cdk server adapter shows error then overridden by adbinfo output
> ----------------------------------------------------------------
>
> Key: JBIDE-21164
> URL: https://issues.jboss.org/browse/JBIDE-21164
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
>
> started cdk from server adapter view.
> starts up - eventually it fails and output contains my username and password in plain text and some error ...then replaced by output of adbinfo.
> A) why was my username/password listed in plain text ? (might be basic vagrant issue not specific to cdk server adapter)
> B) why did output of adbinfo override output from vagrant. should this not be appended or handled separately ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (JBIDE-21159) Cannot get SSL certificate
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21159?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-21159:
-----------------------------------
Assignee: Andre Dietisheim
> Cannot get SSL certificate
> --------------------------
>
> Key: JBIDE-21159
> URL: https://issues.jboss.org/browse/JBIDE-21159
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Environment: openshift 3 tools 3.1.0.Beta1-v20151201-0140-B94
> Reporter: Jan Richter
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: connection, openshift_v3
>
> When trying to log into internal OSE instance, I can't retrieve certificate from the server, therefore it is not possible to establish a new connection. Internal OSE instance also requires to use parameter "--insecure-skip-tls-verify=true" while logging in from 'oc' binary because of some x509 obscurities.
> Stacktrace:
> {noformat}
> com.openshift.restclient.OpenShiftException: javax.net.ssl.SSLHandshakeException while trying to get an authorization context for server https://console.engint.openshift.com
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:141)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getAuthorizationDetails(AuthorizationClient.java:78)
> at com.openshift.internal.restclient.DefaultClient.getAuthorizationDetails(DefaultClient.java:496)
> at org.jboss.tools.openshift.internal.ui.wizard.connection.OAuthDetailView$AuthDetailsJob.run(OAuthDetailView.java:285)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
> at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
> at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
> at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
> at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at com.openshift.internal.restclient.authorization.AuthorizationClient.getContextUsingCredentials(AuthorizationClient.java:134)
> ... 4 more
> Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
> at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(SSLContextImpl.java:1119)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months