August 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-23010) landrush plugin prevents CDK server adapter from starting

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23010?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-23010: ------------------------------------- > Is this something we can resolve on the DevStudio side? On the dev studio side, we are using the "External Tools launch configuration", a very standard launch config in eclipse. All we're doing here is setting the command to run, args, directory, etc. Then we're letting eclipse read the streams, and tell us when the process is complete. So if this is a bug in how one should read streams from a process, then it's burried DEEP in eclipse, and has been for a very long time. To make matters worse, the StreamGobbler example written above actually matches several stackoverflow examples on how to launch a process in java and read it... so it's not just eclipse, but most likely several other java libraries that use similar code. To my knowledge, a process is supposed to terminate whenever the process is naturally complete. The termination of the process will cause the streams to close. In this gist example, the solution seems simple (don't join the gobbler). If we don't join the gobbler, then our little example gist will complete, and close the streams. Sounds good, right? No. Because that's not the way it will work in a long-running application like eclipse that doesn't terminate. Eclipse will still be reading the streams... and the fact that eclipse is still reading the streams will prevent the process from terminating. Again, to repeat, our gist "joining" the gobbler is only to demonstrate the bug. Eclipse doesn't "join" the gobbler, but rather just keeps reading the stream. It is the reading of the stream that prevents the vagrant command from completing, not the "joining" on it. The joining of the gobbler only prevents our little gist from terminating, to demonstrate how a long-running process like eclipse would behave by simply reading the streams. > The return code of vagrant, I believe, will tell you if the box started. We never find out the return code, because the process never completes, because eclipse is still reading the streams, and this prevents vagrant from completing. If you prefer, you could change the 'join' to some type of Thread.sleep loop that checks if the process has completed every 5 seconds for 5 minutes, 10 minutes, 1 hour, 5 hours... ... You will find that the process never completes, and so we can never get a return code. The "join" is not the problem, and the problem is replicatable even if you remove "join" from the examples. > landrush plugin prevents CDK server adapter from starting > --------------------------------------------------------- > > Key: JBIDE-23010 > URL: https://issues.jboss.org/browse/JBIDE-23010 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: cdk, upstream > Affects Versions: 4.4.1.AM3 > Reporter: Martin Malina > Assignee: Rob Stryker > Priority: Critical > > Today I downloaded cdk 2.2.rc1 [1], installed all the vagrant plugins from scratch. And then I first started this from CLI - it wanted password for sudo to set up landrush. (That's another concern I have: How will this work in devstudio? Probably it won't.) > Then I stopped it, set up in devstudio and start there. Everything looks fine, but the server adapter is stuck at "Starting...". > This is the console output: > {code} > Bringing machine 'default' up with 'virtualbox' provider... > ==> default: Clearing any previously set forwarded ports... > ==> default: Clearing any previously set network interfaces... > ==> default: [landrush] virtualbox requires an additional private network; adding it > ==> default: [landrush] starting dns server > ==> default: Preparing network interfaces based on configuration... > default: Adapter 1: nat > default: Adapter 2: hostonly > ==> default: Forwarding ports... > default: 22 (guest) => 2222 (host) (adapter 1) > ==> default: Running 'pre-boot' VM customizations... > ==> default: Booting VM... > ==> default: Waiting for machine to boot. This may take a few minutes... > default: SSH address: 127.0.0.1:2222 > default: SSH username: vagrant > default: SSH auth method: private key > default: Warning: Remote connection disconnect. Retrying... > default: Warning: Remote connection disconnect. Retrying... > default: Warning: Remote connection disconnect. Retrying... > ==> default: Machine booted and ready! > ==> default: Registering box with vagrant-registration... > ==> default: Checking for guest additions in VM... > default: No guest additions were detected on the base box for this VM! Guest > default: additions are required for forwarded ports, shared folders, host only > default: networking, and more. If SSH fails on this machine, please install > default: the guest additions and repackage the box to continue. > default: > default: This is not an error message; everything may continue to work properly, > default: in which case you may ignore this message. > ==> default: Setting hostname... > ==> default: Configuring and enabling network interfaces... > [landrush] Using eth1 (172.28.128.3) > ==> default: [landrush] adding machine entry: cdk.vm => 172.28.128.3 > ==> default: [landrush] adding static DNS entry: cdk => cdk.vm > [landrush] Using eth1 (172.28.128.3) > [landrush] Host DNS resolver config looks good. > ==> default: Copying TLS certificates to /Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker > ==> default: Mounting SSHFS shared folder... > ==> default: Mounting folder via SSHFS: /Users/rasp => /Users/rasp > ==> default: Checking Mount.. > ==> default: Checking Mount.. > ==> default: Folder Successfully Mounted! > ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision` > ==> default: flag to force provisioning. Provisioners marked to run always will still run. > ==> default: Running provisioner: shell... > default: Running: inline script > ==> default: Running provisioner: shell... > default: Running: inline script > ==> default: > ==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory. > ==> default: To modify the number of cores and/or available memory set the environment variables > ==> default: VM_CPU respectively VM_MEMORY. > ==> default: > ==> default: You can now access the OpenShift console on: https://openshift.cdk:8443/console > ==> default: > ==> default: To use OpenShift CLI, run: > ==> default: $ vagrant ssh > ==> default: $ oc login > ==> default: > ==> default: Configured users are (<username>/<password>): > ==> default: openshift-dev/devel > ==> default: admin/admin > ==> default: > ==> default: If you have the oc client library on your host, you can also login from your host. > {code} > These are my plugins: > {code} > $ vagrant plugin list > landrush (1.1.1) > - Version Constraint: 1.1.1 > vagrant-registration (1.2.3) > - Version Constraint: 1.2.3 > vagrant-service-manager (1.3.0) > - Version Constraint: 1.3.0 > vagrant-share (1.1.5, system) > vagrant-sshfs (1.2.0) > - Version Constraint: 1.2.0 > {code} > [1] http://cdk-builds.usersys.redhat.com/builds/weekly/12-Aug-2016.rc1/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ERT-393) Delete multiple images in Docker Explorer [EBZ#499842]

by Friendly Jira Robot (JIRA)

Friendly Jira Robot created ERT-393: --------------------------------------- Summary: Delete multiple images in Docker Explorer [EBZ#499842] Key: ERT-393 URL: https://issues.jboss.org/browse/ERT-393 Project: Eclipse Release Train Issue Type: Task Components: Linux Tools Reporter: Friendly Jira Robot Add possibility to select and delete multiple images from Docker Explorer(This is possible in Docker Images tab). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ERT-394) Pull Image wizard pulls all images if tag is not specified [EBZ#499843]

by Friendly Jira Robot (JIRA)

Friendly Jira Robot created ERT-394: --------------------------------------- Summary: Pull Image wizard pulls all images if tag is not specified [EBZ#499843] Key: ERT-394 URL: https://issues.jboss.org/browse/ERT-394 Project: Eclipse Release Train Issue Type: Task Components: Linux Tools Reporter: Friendly Jira Robot If I enter image name ("jboss/wildfly") in field "Image name:" all images are pulled, not only the tag "latest". Similar issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=474667 Docker tooling version: 2.1.0201608170955 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20664) create discovery site (for testing only) that includes latest IS discovery jars with Core discovery jars so all connectors can be seen in a single place

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20664?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-20664. ------------------------------ Resolution: Rejected Paul's builds of the IS stuff already does all this... no need to reinvent it on the devstudio/jbosstools side. > create discovery site (for testing only) that includes latest IS discovery jars with Core discovery jars so all connectors can be seen in a single place > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20664 > URL: https://issues.jboss.org/browse/JBIDE-20664 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central-update > Affects Versions: 4.3.0.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Now that IS has published some plugins, we can start aggregating them into the output of the JBT CI buils for discovery.central and discovery.earlyaccess. > Here's where I found some jars: > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > Not sure why there's JBDS IS jars on the JBT server, or why there's no Alpha1a for JBDS. [~pleacu] can you help me know which jars to collect into the JBT / JBDS sites? If you need help doing cleanup of old artifacts, let me know. > Also, can you change your publishing process so that you're not dumping dozens of old jars into the same folder? > Have a look here: > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > And contrast that with the way the JBT & JBDS discovery jars are done: > http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-dis... > https://devstudio.redhat.com/9.0/snapshots/builds/jbosstools-discovery.ce... > (using rsync.sh, you get automated build folder cleanup every time you publish a new build, or you can force cleanup it with this job [1]). > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-cleanup/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20664) create discovery site (for testing only) that includes latest IS discovery jars with Core discovery jars so all connectors can be seen in a single place

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20664?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-20664: ------------------------------- Fix Version/s: 4.4.1.Final (was: 4.3.x) > create discovery site (for testing only) that includes latest IS discovery jars with Core discovery jars so all connectors can be seen in a single place > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20664 > URL: https://issues.jboss.org/browse/JBIDE-20664 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central-update > Affects Versions: 4.3.0.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Now that IS has published some plugins, we can start aggregating them into the output of the JBT CI buils for discovery.central and discovery.earlyaccess. > Here's where I found some jars: > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > Not sure why there's JBDS IS jars on the JBT server, or why there's no Alpha1a for JBDS. [~pleacu] can you help me know which jars to collect into the JBT / JBDS sites? If you need help doing cleanup of old artifacts, let me know. > Also, can you change your publishing process so that you're not dumping dozens of old jars into the same folder? > Have a look here: > http://download.jboss.org/jbosstools/mars/staging/updates/integration-sta... > https://devstudio.redhat.com/9.0/staging/updates/integration-stack/discov... > And contrast that with the way the JBT & JBDS discovery jars are done: > http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-dis... > https://devstudio.redhat.com/9.0/snapshots/builds/jbosstools-discovery.ce... > (using rsync.sh, you get automated build folder cleanup every time you publish a new build, or you can force cleanup it with this job [1]). > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-cleanup/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3982) create rh-eclipse46-devstudio rpm for linux installs

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3982?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3982: ----------------------------- Fix Version/s: 10.1.0.GA (was: 10.1.0.AM3) > create rh-eclipse46-devstudio rpm for linux installs > ---------------------------------------------------- > > Key: JBDS-3982 > URL: https://issues.jboss.org/browse/JBDS-3982 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 10.1.0.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 10.1.0.GA > > > wrap new update site (JBDS-3981) in a rh-eclipse46-devstudio*.rpm so we can install it on Fedora 24 and RHEL 7 > will need to port http://download.jboss.org/jbosstools/updates/scripted-install/director.xml to bash so it can be called along with rpmbuilder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3890) Devstudio installation takes a long, long time

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3890?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3890: ----------------------------- Fix Version/s: 10.x (was: 10.1.0.AM3) > Devstudio installation takes a long, long time > ---------------------------------------------- > > Key: JBDS-3890 > URL: https://issues.jboss.org/browse/JBDS-3890 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: installer > Affects Versions: 10.0.0.Alpha1 > Environment: Fedora 22 x64 > OpenJDK 1.8.0_91 > jboss-devstudio-10.0.0.Alpha1-v20160517-0518-B5370-installer-standalone.jar > Reporter: Jan Richter > Priority: Critical > Fix For: 10.x > > Attachments: install.png, res.png > > > Some actual data here: > - Alpha1 (staged) build took 2:05 to install on my machine > - Alpha1 nightly (B5370) took 5:15 to install > Around the minute mark the installation just freezes in this state: > !install.png|thumbnail! > Meanwhile the trace says: > {noformat} > Committing the provisioning operation. > Operation completed in 275702 ms. > {noformat} > That is quite a long time it spent doing that operation. > Some jstack info can be found here: > http://pastebin.test.redhat.com/374700 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22728) Script the process for jbosstools projects to move up to the latest parent pom in their root pom & all-tests pom; verify that changes are valid & push to origin

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22728?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22728: ------------------------------- Sprint: devex #118 July 2016, devex #119 August 2016 (was: devex #118 July 2016) > Script the process for jbosstools projects to move up to the latest parent pom in their root pom & all-tests pom; verify that changes are valid & push to origin > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-22728 > URL: https://issues.jboss.org/browse/JBIDE-22728 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Current process for moving all the JBT projects to the latest parent pom involves generating 15+ JIRAs assigned to the various project leads, so they can all adopt the latest parent pom, verify their build works, and push the change. > With the advent of PR build jobs, we can now streamline this a little: > instead of creating Task JIRAs, create PRs & let them run automatically. > if they pass, push them in automatically (via script that Alexey or Denis would run) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22819) wrap staging build process with a jenkins job

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22819?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22819: ------------------------------- Sprint: devex #118 July 2016, devex #119 August 2016 (was: devex #118 July 2016) > wrap staging build process with a jenkins job > --------------------------------------------- > > Key: JBIDE-22819 > URL: https://issues.jboss.org/browse/JBIDE-22819 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Job requires about 13 params: > {code} > version (JBT and JBDS) > versionWithRespin (JBT and JBDS) > versionWithRespin_PREV (JBT and JBDS) > target platforms (min, max, central) > respin # (- or a, b, c) > devsuite installerExe url > stream_JBT=master # or 4.4.neon > stream_DS=master # or 10.0.neon > {code} > See https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui... for the steps to convert into a job -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22968) if a build fails to publish, future builds may think there's nothing new and also not publish

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22968?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22968: ------------------------------- Fix Version/s: 4.4.1.Final (was: 4.4.1.AM3) > if a build fails to publish, future builds may think there's nothing new and also not publish > --------------------------------------------------------------------------------------------- > > Key: JBIDE-22968 > URL: https://issues.jboss.org/browse/JBIDE-22968 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > Attachments: openshift-failed-future-builds-did-not-publish.png > > > When publishing snapshots to download.jboss.org via Jenkins jobs, we need to add a check for "did the last build fail? if so, set skipRevisionCheckWhenPublishing = true" > That way we don't get situations where the Openshift build fails (because failed enforcer check) and then the next 4-5 builds are NOT published (because as far as the current tests are concerned, the latest SHA in Jenkins == latest SHA in github... but NOT the latest SHA on download.jboss.org/.../snapshots/JOB_NAME/latest/. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues August 2016