[JBoss JIRA] (JBIDE-22646) Starting cdk creates two processes in debug view
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22646?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22646:
-------------------------------------
Since there is no process that we launched, it's expected the process disappears in this case. Generally you only want a process in the view if a process is running that can be identified and terminated. Since we cannot identify the process actually running the VM, we only have the vagrant up process associated with the launch, and once that completes, the process (and thus launch) are completed.
You can contrast this with a remote wildfly startup for example, where we keep the process in the view because we know there is a remote process and we know it's PID. So we simulate the process in that situation.
I'd suggest this is working as expected.
> Starting cdk creates two processes in debug view
> ------------------------------------------------
>
> Key: JBIDE-22646
> URL: https://issues.jboss.org/browse/JBIDE-22646
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk, server
> Affects Versions: 4.4.1.AM1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM1
>
>
> Starting cdk creates two processes in debug view.
> One does not disappear when the startup process is complete.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBDS-3627) Installer needs to help move past lack of t/c signing
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3627?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3627:
-------------------------------------------
I think you must be talking about the old approach since If it was done as I insisted it should work it would work for both eclipse and any other download mechanism :) Anyways.
So David what you are saying is we should make sure installer uses the new approach and that by looking at response values and headers it can figure out links to show the user, right?
> Installer needs to help move past lack of t/c signing
> -----------------------------------------------------
>
> Key: JBDS-3627
> URL: https://issues.jboss.org/browse/JBDS-3627
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Enhancement
> Components: platform-installer
> Reporter: Joshua Wilson
> Assignee: Denis Golovin
> Labels: havoc
> Fix For: 10.1.0.AM2
>
> Attachments: Installer-not-signed-tc.PNG
>
>
> When you login with an active account that hasn't signed the Terms and Conditions the login fails and tells you why but not how to resolve it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[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 Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22728?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-22728:
---------------------------------------------
I did not respond or said anything about what number of jiras are created, I simply pointed out if you remove jira and only have PR's you loose tracking easily what is left to do.
Nothing else. My understanding was that updating parent pom's can't be done reliably for all repos, but if it can then sure by all means have less jiras, just not zero jiras.
btw. wether there is 1 or 17 jiras vs 1 person I think is rather irrelevant since you could use smart commit messages (https://confluence.atlassian.com/fisheye/using-smart-commits-298976812.html) and simply have "JBIDE-xyz #resolve" in the commit message and when the PR gets pushed the jira gets automatically resolved. Then you can could have lets say 13 of these go through easily and have 4 fail and it could be fix by one or more people.
Anyway - tons of flexiblity and automation in this.
> 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.AM3
>
>
> 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, 8 months
[JBoss JIRA] (JBIDE-22446) Release process should disallow inclusion of snapshots artifacts
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22446?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22446:
------------------------------------
Poms are always SNAPSHOT because we don't ever release them. We only publish p2 sites, not maven artifacts.
(There are exceptions to this (such as for jbosstools-build-ci or jbosstools-maven-plugins), but for the jbosstoos-[component-project] repos, this is the case. Since we ALWAYS use snapshots for parent pom, the default rule will fail.)
> Release process should disallow inclusion of snapshots artifacts
> ----------------------------------------------------------------
>
> Key: JBIDE-22446
> URL: https://issues.jboss.org/browse/JBIDE-22446
> Project: Tools (JBoss Tools)
> Issue Type: Release
> Components: build
> Affects Versions: 4.4.0.Alpha2
> Reporter: Jeff MAURY
> Assignee: Nick Boldt
> Fix For: 4.4.1.AM3
>
>
> 4.4.0.Alpha2 was generated with a SNAPSHOT dependency. This should be avoided in future releases even for Alpha ones
> Update: This issues is for adding some automated test/check to detect situation when our release includes a snapshot dependency.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22446) Release process should disallow inclusion of snapshots artifacts
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22446?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22446:
------------------------------------
There's a flag for executing the rule only for release artifacts but I don't know if POMs switch from SNAPSHOT to RELEASE each time we do a release.
> Release process should disallow inclusion of snapshots artifacts
> ----------------------------------------------------------------
>
> Key: JBIDE-22446
> URL: https://issues.jboss.org/browse/JBIDE-22446
> Project: Tools (JBoss Tools)
> Issue Type: Release
> Components: build
> Affects Versions: 4.4.0.Alpha2
> Reporter: Jeff MAURY
> Assignee: Nick Boldt
> Fix For: 4.4.1.AM3
>
>
> 4.4.0.Alpha2 was generated with a SNAPSHOT dependency. This should be avoided in future releases even for Alpha ones
> Update: This issues is for adding some automated test/check to detect situation when our release includes a snapshot dependency.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22225) Debugging for node.js applications on Openshift
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22225?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22225:
------------------------------------
For your code, code OpenShiftServerUtils.getService(server) to get an IService and then call PodDeploymentPathProvider.load to get the path in the pod. Not tested, so let me know if this fiill the gap
> Debugging for node.js applications on Openshift
> -----------------------------------------------
>
> Key: JBIDE-22225
> URL: https://issues.jboss.org/browse/JBIDE-22225
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: javascript, openshift
> Reporter: Gorkem Ercan
> Assignee: Ilya Buziuk
> Labels: debugging, openshift_v3
> Fix For: 4.4.x
>
> Attachments: Screenshot from 2016-07-21 15-29-25.png
>
>
> We should be able to start and connect the new debugger to a node.js application running on Openshift.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22852) Add check for errors in log when cancelling New Project wizard in OpenNewApplicationWizardWithNoProjectTest
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22852?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-22852:
-----------------------------------------------
[~mlabuda], please take a look at the pull request.
> Add check for errors in log when cancelling New Project wizard in OpenNewApplicationWizardWithNoProjectTest
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-22852
> URL: https://issues.jboss.org/browse/JBIDE-22852
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift, qa
> Affects Versions: 4.4.1.AM1
> Reporter: Viacheslav Kabanovich
> Fix For: 4.4.1.AM3
>
>
> There is testOpenNewApplicationWizardFromCentralWithNoProjects that creates new project and checks that the created project is selected in New Application wizard.
> We need a test like testOpenNewApplicationWizardFromOpenShiftExplorerWithNoProjectsAndCancelNewProject that cancels creating new project and (in this case of starting from Openshift explorer) checks that New Application wizard is closed and no errors are logged to the Eclipse log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months