[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:
-------------------------------------
File to use to test? https://gist.github.com/jeffmaury/ba61c91fe910220585e9893540ccec7d
> 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
[JBoss JIRA] (JBIDE-22968) if a build fails to publish, future builds may think there's nothing new and also not publish
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22968?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-22968 at 8/16/16 11:29 AM:
--------------------------------------------------------------------
p2diff deep comparison is not a binary comparison of the IUs but a "deeper" comparison of their p2 metadata:
https://github.com/irbull/p2diff/blob/master/org.eclipse.equinox.p2.examp...
{code}
/**
* Does a deep compare on two IUs. A deep compare will return differences inside
* two IUs (with the same ID), where the differences are more than just 'version' differences.
*
* For example, assume we have two IUs A and B - Where A and B have the same ID but different versions
* The DeepIUCompare will find the parts of these IUs that differ. However, if a part only differs by a version number,
* that is, for example, if all the requirements are the same but the versions are different, this will not be reported.
*
* This tool allows you to find elements that have been added or removed from an IU.
*
{code}
I dont see any checks on IU hash or size, just deeper inspection of the p2 metadata (properties, requirements, etc.)
was (Author: adietish):
p2diff deep comparison is not a binary comparison of the IU binaries but a "deeper" comparison of their p2 metadata:
https://github.com/irbull/p2diff/blob/master/org.eclipse.equinox.p2.examp...
{code}
/**
* Does a deep compare on two IUs. A deep compare will return differences inside
* two IUs (with the same ID), where the differences are more than just 'version' differences.
*
* For example, assume we have two IUs A and B - Where A and B have the same ID but different versions
* The DeepIUCompare will find the parts of these IUs that differ. However, if a part only differs by a version number,
* that is, for example, if all the requirements are the same but the versions are different, this will not be reported.
*
* This tool allows you to find elements that have been added or removed from an IU.
*
{code}
I dont see any checks on IU hash or size, just deeper inspection of the p2 metadata (properties, requirements, etc.)
> 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.AM3
>
> 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
[JBoss JIRA] (JBIDE-22968) if a build fails to publish, future builds may think there's nothing new and also not publish
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22968?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-22968 at 8/16/16 11:29 AM:
--------------------------------------------------------------------
p2diff deep comparison is not a binary comparison of the IU binaries but a "deeper" comparison of their p2 metadata:
https://github.com/irbull/p2diff/blob/master/org.eclipse.equinox.p2.examp...
{code}
/**
* Does a deep compare on two IUs. A deep compare will return differences inside
* two IUs (with the same ID), where the differences are more than just 'version' differences.
*
* For example, assume we have two IUs A and B - Where A and B have the same ID but different versions
* The DeepIUCompare will find the parts of these IUs that differ. However, if a part only differs by a version number,
* that is, for example, if all the requirements are the same but the versions are different, this will not be reported.
*
* This tool allows you to find elements that have been added or removed from an IU.
*
{code}
I dont see any checks on IU hash or size, just deeper inspection of the p2 metadata (properties, requirements, etc.)
was (Author: adietish):
p2diff deep comparison is not a binary comparison of the IUs but a "deeper" comparison of the p2 metadata:
https://github.com/irbull/p2diff/blob/master/org.eclipse.equinox.p2.examp...
{code}
/**
* Does a deep compare on two IUs. A deep compare will return differences inside
* two IUs (with the same ID), where the differences are more than just 'version' differences.
*
* For example, assume we have two IUs A and B - Where A and B have the same ID but different versions
* The DeepIUCompare will find the parts of these IUs that differ. However, if a part only differs by a version number,
* that is, for example, if all the requirements are the same but the versions are different, this will not be reported.
*
* This tool allows you to find elements that have been added or removed from an IU.
*
{code}
I dont see any checks on IU hash or size, just deeper inspection of the p2 metadata (properties, requirements, etc.)
> 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.AM3
>
> 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
[JBoss JIRA] (ERT-387) JSON editor "supports" comments, not supported by JSON [EBZ#499705]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-387:
---------------------------------------
Summary: JSON editor "supports" comments, not supported by JSON [EBZ#499705]
Key: ERT-387
URL: https://issues.jboss.org/browse/ERT-387
Project: Eclipse Release Train
Issue Type: Task
Components: WTP Source Editing
Reporter: Friendly Jira Robot
Priority: Trivial
I tried commenting a line in a JSON file using the common syntax "/* comment */":
/*"jquery/jquery-min": "1.12",*/
This caused the line to become blue, so I figured JSON must support comments. But as mentioned in https://en.wikipedia.org/w/index.php?title=JSON&oldid=734431215 this is not the case.
Ticket #495578 explains that Angelo ZERR decided to support "JSON comments" since .jshintrc (no idea what that is) uses it. In my opinion, this should be disabled by default, but for sure, it should be possible to disable. Currently, all JSON highlights are mandatory (the checkboxes are disabled).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ERT-386) code formatter inserts line breaks after const qualifier [EBZ#399501]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-386:
---------------------------------------
Summary: code formatter inserts line breaks after const qualifier [EBZ#399501]
Key: ERT-386
URL: https://issues.jboss.org/browse/ERT-386
Project: Eclipse Release Train
Issue Type: Task
Components: JSDT
Reporter: Friendly Jira Robot
Priority: Trivial
for a code line like
const FOO = "bar";
the code formatter inserts a line break after the const keyword, resulting in
const
FOO = "bar";
While this simply looks ugly (to me) code verification reports a warning "Missing semicolon", so I get many nasty m,arkers on source files.
Please remove those line breaks or make them settable in the formatter settings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ERT-388) Grunt plugin doesn't see all tasks [EBZ#499729]
by Friendly Jira Robot (JIRA)
Friendly Jira Robot created ERT-388:
---------------------------------------
Summary: Grunt plugin doesn't see all tasks [EBZ#499729]
Key: ERT-388
URL: https://issues.jboss.org/browse/ERT-388
Project: Eclipse Release Train
Issue Type: Task
Components: JSDT
Reporter: Friendly Jira Robot
Priority: Trivial
-- Configuration Details --
Product: Eclipse 4.6.0.20160613-1800 (org.eclipse.epp.package.jee.product)
Installed Features:
org.eclipse.jdt 3.12.0.v20160606-1100
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[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:
-------------------------------------
> So this should really block AM3 release.
I think you mean should NOT block?
> 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
[JBoss JIRA] (JBIDE-23009) Cannot connect to cdk docker in Docker Explorer
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23009?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-23009:
-------------------------------------
> So this should really block AM3 release.
Do you mean should NOT?
> Cannot connect to cdk docker in Docker Explorer
> -----------------------------------------------
>
> Key: JBIDE-23009
> URL: https://issues.jboss.org/browse/JBIDE-23009
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Xavier Coulon
> Priority: Critical
>
> When I start CDK 2.2, docker connection is correctly created, but it cannot connect. There is no error message anywhere.
> If I try to create a connection manually, using details from "vagrant service-manager env", the ping fails and it doesn't work either.
> Connection from CLI, on the other hand, to this docker daemon works fine - when I run the export commands:
> {code}
> export DOCKER_HOST=tcp://172.28.128.3:2376
> export DOCKER_CERT_PATH=/Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> export DOCKER_TLS_VERIFY=1
> export DOCKER_API_VERSION=1.22
> {code}
> and then try for example "docker ps" or "docker run hello-world".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23009) Cannot connect to cdk docker in Docker Explorer
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23009?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-23009:
---------------------------------------
Did you mean
{quote}
it should *NOT* block AM3 release
{quote}
instead ?
> Cannot connect to cdk docker in Docker Explorer
> -----------------------------------------------
>
> Key: JBIDE-23009
> URL: https://issues.jboss.org/browse/JBIDE-23009
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Xavier Coulon
> Priority: Critical
>
> When I start CDK 2.2, docker connection is correctly created, but it cannot connect. There is no error message anywhere.
> If I try to create a connection manually, using details from "vagrant service-manager env", the ping fails and it doesn't work either.
> Connection from CLI, on the other hand, to this docker daemon works fine - when I run the export commands:
> {code}
> export DOCKER_HOST=tcp://172.28.128.3:2376
> export DOCKER_CERT_PATH=/Users/rasp/jbossqa/cdk2.2.rc1/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> export DOCKER_TLS_VERIFY=1
> export DOCKER_API_VERSION=1.22
> {code}
> and then try for example "docker ps" or "docker run hello-world".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23013) Pull Docker Tooling bits into JBT builds more frequently
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23013?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23013:
------------------------------------
The other option would be to treat docker/vagrant tooling like a first-class component of JBoss Tools, and fetch it into the JBT aggregate site, rather than the target platform.
We've done this for other 3rd party things like tern, angular, etc.
> Pull Docker Tooling bits into JBT builds more frequently
> --------------------------------------------------------
>
> Key: JBIDE-23013
> URL: https://issues.jboss.org/browse/JBIDE-23013
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, target-platform
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Nick Boldt
>
> It would be cool if we could update the Docker Tooling bits in our TP more frequently, i.e. weekly or even nightly. I know that currently it is quite a big effort to update TP. So we would need to simplify this somehow.
> So this is a suggestion, but I don't know how we would do it or if it's doable at all.
> Here's a bit of background:
> Today I spotted this blocking bug in docker tooling:
> https://issues.jboss.org/browse/JBIDE-23011
> It was probably brought into JBT TP in the last update of the TP - this JIRA:
> https://issues.jboss.org/browse/JBIDE-22885 - 4 days ago.
> Jeff Maury suggested, that it's a bad idea to update our TP this close to our release (AM3 in this case). But currently we don't have any other option.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months