[JBoss JIRA] (JBIDE-21937) Application Wizard: if git clone directory already exist i cannot do anything
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21937?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-21937:
----------------------------------
Fix Version/s: (was: 4.3.1.CR1)
> Application Wizard: if git clone directory already exist i cannot do anything
> -----------------------------------------------------------------------------
>
> Key: JBIDE-21937
> URL: https://issues.jboss.org/browse/JBIDE-21937
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Labels: application_wizard
> Fix For: 4.4.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21937) Application Wizard: if git clone directory already exist i cannot do anything
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21937?page=com.atlassian.jira.plugi... ]
Marián Labuda resolved JBIDE-21937.
-----------------------------------
Resolution: Done
> Application Wizard: if git clone directory already exist i cannot do anything
> -----------------------------------------------------------------------------
>
> Key: JBIDE-21937
> URL: https://issues.jboss.org/browse/JBIDE-21937
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Labels: application_wizard
> Fix For: 4.4.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21935) resue flow in clone wizard is ambigious
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21935?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-21935:
----------------------------------
Affects Version/s: 4.3.1.CR1
> resue flow in clone wizard is ambigious
> ---------------------------------------
>
> Key: JBIDE-21935
> URL: https://issues.jboss.org/browse/JBIDE-21935
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Max Rydahl Andersen
>
> continuation of JBIDE-14828:
> with the intended behavior explained then lets make that visible to the user:
> a) don't hide/show controls in a wizard, enable/disable them.
> b) The "Reuse" is ambiguous, i.e. I read it as the clone will happen into this folder, not that it will do exactly the opposite of what the wizard says (not clone). I suggest something like "Do not clone - reuse existing folder".
> c) if not already there, add a check that what is inside the folder is actually a clone of what we are trying to clone.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21936) Disable livereload context menu on stopped server modules
by Jan Richter (JIRA)
Jan Richter created JBIDE-21936:
-----------------------------------
Summary: Disable livereload context menu on stopped server modules
Key: JBIDE-21936
URL: https://issues.jboss.org/browse/JBIDE-21936
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: livereload
Affects Versions: 4.3.1.CR1
Reporter: Jan Richter
Similar to JBIDE-21517, but this time the server is running, but the deployed project is not. Both the context menu for show in via livereload and the quick access command are enabled for a stopped module. And they just open a browser tab with 404 - not found.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21845) Docker connection does not work with CDK build 2016-03-09
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21845?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21845:
---------------------------------------
[~sigreen], I believe what you're seeing is this: https://github.com/projectatomic/vagrant-service-manager/issues/80
Vagrant-service-manager 0.0.4 is affected. It will be fixed in a newer version.
Sorry, I should have mentioned it here.
> Docker connection does not work with CDK build 2016-03-09
> ---------------------------------------------------------
>
> Key: JBIDE-21845
> URL: https://issues.jboss.org/browse/JBIDE-21845
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, upstream
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Hardy Ferentschik
> Priority: Blocker
> Fix For: 4.3.1.CR1
>
>
> Today I tried cdk build 2016-03-09 in JBDS 9.1.0.CR1 (build from 2 days ago).
> I start cdk, the docker connection is created, but it doesn't work:
> {code}
> org.eclipse.linuxtools.docker.core.DockerException: com.spotify.docker.client.DockerException: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.listImages(DockerConnection.java:787)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.getImages(DockerConnection.java:750)
> at org.eclipse.linuxtools.internal.docker.ui.views.DockerExplorerContentProvider$5.run(DockerExplorerContentProvider.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: com.spotify.docker.client.DockerException: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at com.spotify.docker.client.DefaultDockerClient.propagate(DefaultDockerClient.java:1141)
> at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:1072)
> at com.spotify.docker.client.DefaultDockerClient.listImages(DefaultDockerClient.java:354)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.listImages(DockerConnection.java:780)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:293)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:1070)
> ... 5 more
> Caused by: javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:517)
> at org.glassfish.jersey.apache.connector.ApacheConnector$1.run(ApacheConnector.java:527)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at jersey.repackaged.com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:49)
> at jersey.repackaged.com.google.common.util.concurrent.AbstractListeningExecutorService.submit(AbstractListeningExecutorService.java:45)
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:523)
> at org.glassfish.jersey.client.ClientRuntime$1.run(ClientRuntime.java:169)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
> at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
> at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:320)
> at org.glassfish.jersey.client.ClientRuntime$2.run(ClientRuntime.java:201)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> 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:1506)
> 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:72)
> at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:469)
> ... 20 more
> Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:352)
> at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:260)
> at sun.security.validator.Validator.validate(Validator.java:260)
> at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1488)
> ... 39 more
> Caused by: java.security.cert.CertPathValidatorException: signature check failed
> at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
> at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
> at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
> at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
> at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:347)
> ... 45 more
> Caused by: java.security.SignatureException: Signature does not match.
> at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:424)
> at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166)
> at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147)
> at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
> ... 50 more
> {code}
> This looks similar to JBIDE-21733 . But in this case it doesn't work even from terminal:
> {code}
> $ eval "$(vagrant service-manager env docker)"
> $ docker ps
> An error occurred trying to connect: Get https://10.1.2.2:2376/v1.20/containers/json: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "example.com")
> {code}
> So yeah, this does not seem like the problem is on our site, but let's keep this JIRA for tracking anyway.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21924) Various broken icons in menus on OS X
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21924?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-21924:
----------------------------------
Description:
For some time now I've had problems with icons disappearing or just being malformed in Eclipse IDE. I thought it was connected to the fact that I was running JBDS using cli which is not the right way (I did this to overcome an issue where cdk was missing PATH).
But now I'm running JBDS normally and I still have this issue. I'm mostly using Oracle JDK 1.8
!broken-icons.png|thumbnail!
was:
For some time now I've had problems with icons disappearing or just being malformed in Eclipse IDE. I thought it was connected to the fact that I was running JBDS using cli which is not the right way (I did this to overcome an issue where cdk was missing PATH).
But now I'm running JBDS normally and I still have this issue.
!broken-icons.png|thumbnail!
> Various broken icons in menus on OS X
> -------------------------------------
>
> Key: JBIDE-21924
> URL: https://issues.jboss.org/browse/JBIDE-21924
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Fix For: 4.4.x
>
> Attachments: broken-icons.png
>
>
> For some time now I've had problems with icons disappearing or just being malformed in Eclipse IDE. I thought it was connected to the fact that I was running JBDS using cli which is not the right way (I did this to overcome an issue where cdk was missing PATH).
> But now I'm running JBDS normally and I still have this issue. I'm mostly using Oracle JDK 1.8
> !broken-icons.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-14828) Application Wizard: if git clone directory already exist i cannot do anything
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14828?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-14828:
---------------------------------------------
opened JBIDE-21935 for this issue.
> Application Wizard: if git clone directory already exist i cannot do anything
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14828
> URL: https://issues.jboss.org/browse/JBIDE-14828
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Labels: application_wizard
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-21935) resue flow in clone wizard is ambigious
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-21935:
-------------------------------------------
Summary: resue flow in clone wizard is ambigious
Key: JBIDE-21935
URL: https://issues.jboss.org/browse/JBIDE-21935
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Reporter: Max Rydahl Andersen
continuation of JBIDE-14828:
with the intended behavior explained then lets make that visible to the user:
a) don't hide/show controls in a wizard, enable/disable them.
b) The "Reuse" is ambiguous, i.e. I read it as the clone will happen into this folder, not that it will do exactly the opposite of what the wizard says (not clone). I suggest something like "Do not clone - reuse existing folder".
c) if not already there, add a check that what is inside the folder is actually a clone of what we are trying to clone.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-14828) Application Wizard: if git clone directory already exist i cannot do anything
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14828?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-14828:
---------------------------------------------
with the intended behavior explained then lets make that visible to the user:
a) don't hide/show controls in a wizard, enable/disable them.
b) The "Reuse" is ambiguous, i.e. I read it as the clone will happen into this folder, not that it will do exactly the opposite of what the wizard says (not clone). I suggest something like "Do not clone - reuse existing folder".
c) if not already there, add a check that what is inside the folder is actually a clone of what we are trying to clone.
> Application Wizard: if git clone directory already exist i cannot do anything
> -----------------------------------------------------------------------------
>
> Key: JBIDE-14828
> URL: https://issues.jboss.org/browse/JBIDE-14828
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Assignee: Rob Stryker
> Labels: application_wizard
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
> Attachments: application-folder-already-exists.png
>
>
> steps to reproduce:
> # EXEC: create and/or import some appliaction from OpenShift to your local workspace using the application/import wizard
> # EXEC: once you have the project imported to your workspace, delete it
> # EXEC: once it is deleted, go and try to re-import the very same application
> Result:
> The 3rd wizard page errors on the git cloning destination. You're told that the destination folder already exists within the clone destination folder. The only way out currently is to choose a different clone destination folder.
> !application-folder-already-exists.png!
> Expected:
> It would help a lot if wizard would allow you to overwrite the existing destination. The wizard could also check if the given folder holds a prior clone and then allow one to "reuse" this folder. The given folder would then simply get imported to Eclipse and we'd fetch instead of cloning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years