[JBoss JIRA] (JBTIS-795) JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default
by Rick Wagner (JIRA)
[ https://issues.jboss.org/browse/JBTIS-795?page=com.atlassian.jira.plugin.... ]
Rick Wagner updated JBTIS-795:
------------------------------
Attachment: A_camel_service.tar.gz
> JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default
> ----------------------------------------------------------------------------
>
> Key: JBTIS-795
> URL: https://issues.jboss.org/browse/JBTIS-795
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: Fuse IDE
> Affects Versions: 9.0.0.Beta1
> Environment: JBDS 9.1 with devstudio-integration-stack-9.0.0.Beta1-earlyaccess.zip
> Reporter: Rick Wagner
> Assignee: Brian Fitzpatrick
> Attachments: A_camel_service.tar.gz
>
>
> A user has noted that Camel routes used in SwitchYard are now being given an Id without user input. This is a changed behavior.
> The same user complains of very slow loading of SwitchYard/Camel component routes, but this is still under investigation in the cited support ticket.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22079) Import wizard: Error when import a project already existing in workspace
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22079?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-22079:
-----------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> Import wizard: Error when import a project already existing in workspace
> ------------------------------------------------------------------------
>
> Key: JBIDE-22079
> URL: https://issues.jboss.org/browse/JBIDE-22079
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: import_wizard, openshift_v3
> Fix For: 4.4.x
>
> Attachments: import-error.png
>
>
> When I am creating a new OpenShift application using an existing repo, or at least project in workspace, it throws an error upon application creation completion. This is a bit of pain, because even I have an existing git repo and checked the checkbox in Import Wizard to reuse it, it tries to import project then, but it fails. But the existing project is still usable to use it for a new OpenShift 3 server adapter and upon start of the adapter, local changes are published to OpenShift. This issue is just about error. Maybe we could display a dialog that such a project already exists in workspace and let user to choose to replace it by the one being imported or keep it as it is (if user know that the project in workspace is the correct one and he/she does not want to overwrite it and let local changes disappear).
> Error:
> {code}Could not import project from org.jboss.tools.openshift.internal.common.ui.application.importoperation.ImportFailedException: There was a maven related error that prevented us from importing the project. We encourage you to look into the pom in the cloned repository at /home/mlabuda/git/jboss-eap-quickstarts.
> One of the possible reasons is that there is already a project in your workspace that matches the maven name of the OpenShift application. You can then rename your workspace project and start over again.
> An exception stack trace is not available.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21608) "Show In -> Web Browser via Live Reload" on EJB module should be disabled
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21608?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21608:
-----------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> "Show In -> Web Browser via Live Reload" on EJB module should be disabled
> -------------------------------------------------------------------------
>
> Key: JBIDE-21608
> URL: https://issues.jboss.org/browse/JBIDE-21608
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: livereload
> Affects Versions: 4.3.1.Beta2
> Reporter: Martin Malina
> Assignee: Dmitry Bocharov
> Fix For: 4.4.x
>
>
> This is a followup of JBIDE-21138 . When you deploy an ejb module, all the items in Server View under Show in are enabled, but they don't do anything. They should be disabled.
> Rob did his part for Show in Server, but he says separate JIRAs are needed in other components.
> So for Livereload, there are these two items that should be disabled on an ejb module:
> Show in -> Web Browser via Livereload
> Show in -> Web Browser on External device
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21936) Disable livereload context menu on stopped server modules
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21936?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21936:
-----------------------------------
Sprint: devex #117 July 2016 (was: devex #116 June 2016)
> 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
> Assignee: Dmitry Bocharov
> Fix For: 4.4.x
>
>
> 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)
9 years, 9 months
[JBoss JIRA] (JBDS-3961) CDK installation failed with progress bar stuck in 99%
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3961?page=com.atlassian.jira.plugin.... ]
Denis Golovin reassigned JBDS-3961:
-----------------------------------
Assignee: Denis Golovin
> CDK installation failed with progress bar stuck in 99%
> ------------------------------------------------------
>
> Key: JBDS-3961
> URL: https://issues.jboss.org/browse/JBDS-3961
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Environment: h3. Operating System:
> Windows 10 Pro 64 Bit
> h3. Devstudio version
> Devstudio 1.0 GA
> Reporter: Budh Ram Gurung
> Assignee: Denis Golovin
> Labels: cdk
> Fix For: 10.0.1.AM2
>
> Attachments: dev_studio_installation.PNG, install.log
>
>
> I was trying the "devstudio 1.0 GA build" ("development-suite-1.0.0-GA-bundle-installer.exe") and unable to get CDK installation after gone through the steps of authentication, vagrant, cygwin, jboss dev studio installations.
> Observations:
> CDK installation stuck in 99% with "failed" mark.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22686) Can't push image to docker registry
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22686?page=com.atlassian.jira.plugi... ]
Hardy Ferentschik commented on JBIDE-22686:
-------------------------------------------
Is this still happening? Reproducibly? It might be that xip.io was down for a bit which made it unreachable. If this is still an issue can we verify independently from tooling that you can login to the docker registry?
{code}
$ oc login 10.1.2.2:8443 -u openshift-dev -p devel
$ docker login -u openshift-dev -p `oc whoami -t` -e foo(a)bar.com hub.openshift.rhel-cdk.10.1.2.2.xip.io
{code}
> Can't push image to docker registry
> -----------------------------------
>
> Key: JBIDE-22686
> URL: https://issues.jboss.org/browse/JBIDE-22686
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: docker, openshift
> Affects Versions: 4.4.0.Final
> Environment: Fedora 23
> Reporter: Dmitry Bocharov
> Assignee: Dmitry Bocharov
> Attachments: DeployDockerImageToOS.webm
>
>
> The screencast of the last steps is attached.
> Properties and settings of the cdk haven't been changed. Everything is dowloaded and installed in a usual way.
> Possibly something is with the dns - maybe it wasn't configured correctly while cdk installation. Because we to push to the valid url, while OS connection only an IP in its settings.
> _exception:_
> org.eclipse.linuxtools.docker.core.DockerException: com.spotify.docker.client.DockerException: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.pushImage(DockerConnection.java:1047)
> at org.jboss.tools.openshift.internal.ui.dockerutils.PushImageToRegistryJob.doRun(PushImageToRegistryJob.java:67)
> at org.jboss.tools.openshift.internal.common.core.job.AbstractDelegatingMonitorJob.run(AbstractDelegatingMonitorJob.java:37)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: com.spotify.docker.client.DockerException: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.core.DockerProgressHandler.progress(DockerProgressHandler.java:42)
> at com.spotify.docker.client.ProgressStream.tail(ProgressStream.java:74)
> at com.spotify.docker.client.DefaultDockerClient.push(DefaultDockerClient.java:821)
> at org.eclipse.linuxtools.internal.docker.core.DockerConnection.pushImage(DockerConnection.java:1043)
> ... 3 more
> Caused by: org.eclipse.linuxtools.docker.core.DockerImagePushFailedException: Image push failed: hub.openshift.rhel-cdk.10.1.2.2.xip.io/sample-project/aloha: unable to ping registry endpoint https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v0/
> v2 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v2/: dial tcp 10.1.2.2:443: connection refused
> v1 ping attempt failed with error: Get https://hub.openshift.rhel-cdk.10.1.2.2.xip.io/v1/_ping: dial tcp 10.1.2.2:443: connection refused
> at org.eclipse.linuxtools.internal.docker.ui.views.ImagePushProgressHandler.processMessage(ImagePushProgressHandler.java:49)
> at org.eclipse.linuxtools.internal.docker.core.DockerProgressHandler.progress(DockerProgressHandler.java:40)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22673) Need better duplicate IU detection when validating target platforms
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22673?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-22673:
-----------------------------------
Component/s: upstream
> Need better duplicate IU detection when validating target platforms
> -------------------------------------------------------------------
>
> Key: JBIDE-22673
> URL: https://issues.jboss.org/browse/JBIDE-22673
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build, target-platform, upstream
> Affects Versions: 4.4.0.Final
> Reporter: Nick Boldt
> Fix For: 4.4.1.AM1
>
>
> As discussed in JBIDE-22633, we have no way of knowing when the target platform SHOULD contain duplicate IUs, and when it should not.
> {quote}Problem is there's no way to identify easily which dupes are OK and which are not. I suppose I could crack open all the jars and see which are singletons...?
> Or add a whitelist?{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-19081) Use simpler Surefire include/exclude pattern in parent pom
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19081?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19081:
------------------------------------
Here's a quick way to parse locally generated surefire test logs for a count of tests run per test, then count up the total number of classes and tests run, too.
I've also parsed out numbers for Failures, Errors and Skips, so you can track if test statuses change.
For example, run this in the folder where you have jbosstools-openshift checked out:
{code}
echo "Total, Run, Failures, Errors, Skips :: path/to/surefire-reports/class-file.txt"
num=0; tot=0; tests=$(find */*/*/target/surefire-reports/ */*/target/surefire-reports/ -mindepth 1 -maxdepth 1 -name "*.txt" 2>/dev/null|sort); for d in $tests; do (( num++ )); cnt=""; cnt=$(cat $d | grep -v "Tests run" | grep "Time elapsed" | wc -l); tot=$(( tot + cnt )); cat $d | grep "Tests run" | sed "s#Tests run: \([0-9]\+\), Failures: \([0-9]\+\), Errors: \([0-9]\+\), Skipped: \([0-9]\+\), Time elapsed: .\+ in \(.\+\).*#\1 ${cnt} \2 \3 \4 :: ${d}#"; done; echo ""; echo "Total classes: $num"; echo "Total tests run: $tot"
{code}
Output looks like this:
{code}
Total, Run, Failures, Errors, Skips :: path/to/surefire-reports/class-file.txt
3 3 0 0 0 :: tests/org.jboss.tools.openshift.cdk.server.test/target/surefire-reports/org.jboss.tools.openshift.cdk.server.test.internal.CDKDockerUtilityTest.txt
1 1 0 0 0 :: tests/org.jboss.tools.openshift.cdk.server.test/target/surefire-reports/org.jboss.tools.openshift.cdk.server.test.internal.CDKLaunchControllerTest.txt
...
4 3 0 0 1 :: tests/org.jboss.tools.openshift.test/target/surefire-reports/org.jboss.tools.openshift.test.core.connection.ConnectionPersistencyTest.txt
...
1 0 0 0 1 :: tests/org.jboss.tools.openshift.test/target/surefire-reports/org.jboss.tools.openshift.test.ui.wizard.deployimage.search.DockerHubRegistryTest.txt
...
4 4 0 0 0 :: tests/org.jboss.tools.openshift.test/target/surefire-reports/org.jboss.tools.openshift.test.ui.wizard.newapp.TemplateParameterViewerUtilsTest.txt
Total classes: 93
Total tests run: 626
{code}
or
{code}
Total, Run, Failures, Errors, Skips :: path/to/surefire-reports/class-file.txt
12 12 0 0 0 :: common/tests/org.jboss.tools.common.core.test/target/surefire-reports/org.jboss.tools.common.core.test.CommonCoreTestSuite.txt
...
1 0 0 0 1 :: common/tests/org.jboss.tools.common.verification.ui.test/target/surefire-reports/org.jboss.tools.common.verification.ui.test.VerificationUiAllTests.txt
...
50 50 0 0 0 :: usage/tests/org.jboss.tools.usage.test/target/surefire-reports/org.jboss.tools.usage.test.UsageTestSuite.txt
Total classes: 21
Total tests run: 343
{code}
Then you can diff that will another test run to see if either a line is missing (test class didn't run) or the count is different (tests within the class didn't run).
> Use simpler Surefire include/exclude pattern in parent pom
> ----------------------------------------------------------
>
> Key: JBIDE-19081
> URL: https://issues.jboss.org/browse/JBIDE-19081
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 4.4.x
>
>
> 1. In JBDS9, use these new default patterns for Surefire to define which test classes to run/exclude:
> {code}
> include = *Test*, *Test, *TestCase
> exclude = *Abstract*
> {code}
> 2. If that causes test failures because running incorrectly named
> abstract stuff, they can refactor, add their own root pom overrides, use
> a TestSuite, or use @Ignore in test classes.
> 3. If the count of tests run suddenly DROPS because the pattern isn't
> running the correct # of tests, they can add their own root pom
> overrides, or use a TestSuite.
> Ref: http://lists.jboss.org/pipermail/jbosstools-dev/2015-January/009688.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months