[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25858:
---------------------------------------
[~rob.stryker], I just a tried the latest nightly of devstudio and I don't see any change. You're saying that runtime detection is now based on path to minishift binary and not minishift home. But I installed a new installation of devstudio, started it and it already has a cdk adapter. I checked runtime detection and it has the same path included as before - ~/.minishift. And the adapter has empty binary and minishift home is setup. How does this work?
I tried adding ~/tmp to runtime detection and it did find my cdk binary there, so year, that seems to work. (Although the binary path will be missing in the newly created adapter, but that seems to be a separate bug that you will fix.)
So the question is: How come there is still an adapter added when I start devstudio? It seems to me that runtime detection will now work both paths - either path to minishift home or path to search for minishift binary. Is that the case?
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25819) Error building projects from central with java 9
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25819?page=com.atlassian.jira.plugi... ]
Jeff MAURY reassigned JBIDE-25819:
----------------------------------
Assignee: Jeff MAURY
> Error building projects from central with java 9
> ------------------------------------------------
>
> Key: JBIDE-25819
> URL: https://issues.jboss.org/browse/JBIDE-25819
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Jeff MAURY
> Labels: java9
> Fix For: 4.5.x
>
> Attachments: html5-error.png
>
>
> I tried creating the html5 project (or the java ee web project and perhaps others) from Red Hat Central and I got this error:
> {code}
> Errors occurred during the build.
> Errors running builder 'Maven Project Builder' on project 'jboss-as-kitchensink-html5-mobile'.
> Could not initialize class org.codehaus.plexus.archiver.jar.JarArchiver
> {code}
> The project was created anyway, but was not deployable.
> !html5-error.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-25858:
-------------------------------
Sprint: devex #147 April 2018
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25861) Docker connection throws DockerTimeoutException with warning in error log when CDK is stopped
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25861?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-25861:
-------------------------------
Labels: upstream (was: )
> Docker connection throws DockerTimeoutException with warning in error log when CDK is stopped
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-25861
> URL: https://issues.jboss.org/browse/JBIDE-25861
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, docker
> Affects Versions: 4.5.3.AM3
> Environment: Fedora 27 x86_64
> Reporter: Ondrej Dockal
> Labels: upstream
> Fix For: 4.5.x
>
>
> After the docker connection is interrupted by force, there is written to console endless output from docker connection:
> {code}
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25861) Docker connection throws DockerTimeoutException with warning in error log when CDK is stopped
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25861?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-25861:
-------------------------------
Fix Version/s: 4.5.x
> Docker connection throws DockerTimeoutException with warning in error log when CDK is stopped
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-25861
> URL: https://issues.jboss.org/browse/JBIDE-25861
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, docker
> Affects Versions: 4.5.3.AM3
> Environment: Fedora 27 x86_64
> Reporter: Ondrej Dockal
> Fix For: 4.5.x
>
>
> After the docker connection is interrupted by force, there is written to console endless output from docker connection:
> {code}
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: Retrying request to {}->unix://localhost:80
> Mar 26, 2018 11:39:08 PM org.apache.http.impl.execchain.RetryExec execute
> INFO: I/O exception (java.io.IOException) caught when processing request to {}->unix://localhost:80: No such file or directory
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25866) Schema files for WildFly 12 are missing
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25866?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-25866:
-------------------------------
Fix Version/s: 4.5.x
> Schema files for WildFly 12 are missing
> ---------------------------------------
>
> Key: JBIDE-25866
> URL: https://issues.jboss.org/browse/JBIDE-25866
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.x
>
>
> I accidentally found out that schema files that are new in WildFly 12 haven't been added to org.jboss.tools.as.catalog plugin, for instance jboss-web_12_0.xsd (I'm not sure if there are more).
> Why I found out is that I was just trying to verify and close this older JIRA:
> JBIDE-25102 Add "jboss-web-11_0.xsd" to catalog
> And since then we now have WildFly 12 too.
> So this is something to keep in mind when adding a new server adapter.
> Also, please check if this needs to be added to https://github.com/robstryker/jboss.org.schema too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBIDE-25858) Minishift binary is not set up after CDK runtime download
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-25858?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-25858:
---------------------------------------
Good to hear about that change, I wasn't aware! Thanks!
> Minishift binary is not set up after CDK runtime download
> ---------------------------------------------------------
>
> Key: JBIDE-25858
> URL: https://issues.jboss.org/browse/JBIDE-25858
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.3.AM3
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> This is a followup of JBIDE-25835 .
> Recently a new feature was added - cdk can be downloaded directly from the IDE now.
> As with other runtimes, there are two main paths you can take:
> a) New Server -> Download
> b) Preferences -> Runtime Detection -> Download
> tl;dr: b) doesn't work properly with cdk because minishift binary is still not set after the download.
> There is quite a big difference between a) and b). With a), you are adding a server manually and once your download is finished, the correct path is predefined for you. Runtime detection is not involved.
> With b), the server is downloaded, extracted and then the path is added to runtime detection which is in turn run. This will result in the new server being detected and added.
> Now cdk should theoretically support both of these paths. a) works - you're in the middle of adding a cdk server manually, you invoke the download and once that's done, the minishift binary field is filled properly for you.
> But b) doesn't work properly for cdk, because runtime detection for cdk is built around your minishift home and not the minishift binary path. (I don't really know why that's the case, but I guess you had a good reason for it.) So when you do b), cdk binary is downloaded, but what's added to runtime detection is ~/.minishift (or $MINISHIFT_HOME if set). The result is that the cdk server adapter is added once the download is finished, but the minishift binary remains empty. So the usefulness of this feature is questionable.
> Maybe you will say that there is no way to fix this. I hope you will at least agree that this is not ideal and b) doesn't really work properly right now.
> I don't know what the proper solution for this is but let me start with a question: Wouldn't it make sense to change runtime detection of cdk so that it uses the minishift binary as the main path? What's stopping us from doing that?
> Sorry for the lengthy description, I felt I needed to explain the whole context here.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months