[JBoss JIRA] (JBDS-3843) For JBDS 10.0.0.Alpha1: Find Missing Commits From jbosstools-4.3.x for master
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3843?page=com.atlassian.jira.plugin.... ]
Nick Boldt closed JBDS-3843.
----------------------------
Assignee: Nick Boldt (was: Denis Golovin)
Resolution: Done
Marking as done since there are no linked deltas in this issue.
[~rob.stryker] is there a bug in your code such that no URLs are produced for this issue?
> For JBDS 10.0.0.Alpha1: Find Missing Commits From jbosstools-4.3.x for master
> -----------------------------------------------------------------------------
>
> Key: JBDS-3843
> URL: https://issues.jboss.org/browse/JBDS-3843
> Project: Red Hat Developer Studio (DevStudio)
> Issue Type: Task
> Components: installer
> Reporter: Rob Stryker
> Assignee: Nick Boldt
> Priority: Blocker
> Labels: task
> Fix For: 10.0.0.Alpha1
>
>
> For JBDS 10.0.0.Alpha1: Ensure all commits pushed to jbosstools-4.3.x have either been made in master, or are intentionally excluded from master.
> Below are listed all commits made to jbosstools-4.3.x that have not been found in master. It is possible these commits do exist in master, but the patches are not identical. It is also possible that the commits made in jbosstools-4.3.x are not relevant to master or should not be applied.
> If there are no commits listed below, please close (do not resolve) this issue.
> Otherwise:
> 1) Click on each link below.
> 2) Evaluate whether the given commit *should* be in master
> 3) If it should be in master, please find out why it is not in master. You may need to browse master's commit log to find a commit that should match.
> 4) If you cannot find a matching commit, and it *should* be committed to master, please cherry-pick that commit to master or otherwise merge it in.
> 5) In comments, please indicate any suspicious commits (ie, commits not related to simple version changes), whether it exists in master, whether you have successfully merged it in now, or whether it is not intended to be committed to master or is inappropriate for master.
> 6) When all complete, please close (do not resolve) this issue.
>
> [Search for all task JIRA|https://issues.jboss.org//issues/?jql=%28%28project+in+%28JBDS%29+an...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-21230) Show In - Web Browser is enabled and do nothing when there are no routes
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21230?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21230.
---------------------------------
Verified in Red Hat Developer Studio 10.0.0.Alpha1 B5264.
> Show In - Web Browser is enabled and do nothing when there are no routes
> ------------------------------------------------------------------------
>
> Key: JBIDE-21230
> URL: https://issues.jboss.org/browse/JBIDE-21230
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.4.0.Alpha1
>
>
> When I am having a project with an application without any route, the Show In - Web Browser context menu of a project is enabled for this project and it does not do anything (after click nothing happens). Context menu should be disable if there are no routes for an application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-20904) automate publishing latest CI build to staging, then from staging to development (or stable)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-20904:
-------------------------------
Sprint: (was: devex #113 April 2016)
> automate publishing latest CI build to staging, then from staging to development (or stable)
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-20904
> URL: https://issues.jboss.org/browse/JBIDE-20904
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> Suggestion:
> rather than opening 10 bash terminals to perform the copy-from-one-place-on-disk-to-local, copy-from-local-to-another-place steps required to clone CI bits to Stage or from Stage to release, [~mickael_istria] and I discovered today that we could use `wait` or `parallel` to orchestrate these steps via a bash script so they run in parallel (as quickly as possible), but still return feedback when all parallel steps are completed.
> So, where today we run these steps sorta-by-hand (copy script into a console and wait until it's done) [1], in future we could simply kick a job and wait for the job to notify its completion.
> [1] https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui...
> Examples of using a series of commands in parallel w/ a wait at the end:
> http://stackoverflow.com/questions/19543139/bash-script-processing-comman...
> {code:title=spawns the 3 parallel steps, waits until #3 is done (2 seconds later) and returns the PID of the last one + its return code}
> echo "1" & echo 2 & (sleep 2;echo 3) & wait && echo $! $#
> {code}
> More discussion:
> {quote}
> [12:44:46 PM] Mickael Istria: I believe some parts would have to be turned into functions
> [12:54:41 PM] Mickael Istria: so, to hack the script, it could be just:
> * add && after the 1st rsync in each loop
> * add & after the last one
> * put a wait after the last loop
> * give the big piece of code to procede directly to bash
> {quote}
> After this job is done, releng would still have to "wire up" the new bits by updating composite*.xml and index.html pages, but that's considerably easier to do locally in a terminal, or even to script too. Rather than updating these files w/ sed, we could generate them from a template.
> And if we don't care about committing those changes back to github, we could even push them to the dl.jb.o and ds.jb.c servers directly as part of the above job.
> Scary, but much faster!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-20904) automate publishing latest CI build to staging, then from staging to development (or stable)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-20904:
-------------------------------
Sprint: devex #115 May 2017
> automate publishing latest CI build to staging, then from staging to development (or stable)
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-20904
> URL: https://issues.jboss.org/browse/JBIDE-20904
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> Suggestion:
> rather than opening 10 bash terminals to perform the copy-from-one-place-on-disk-to-local, copy-from-local-to-another-place steps required to clone CI bits to Stage or from Stage to release, [~mickael_istria] and I discovered today that we could use `wait` or `parallel` to orchestrate these steps via a bash script so they run in parallel (as quickly as possible), but still return feedback when all parallel steps are completed.
> So, where today we run these steps sorta-by-hand (copy script into a console and wait until it's done) [1], in future we could simply kick a job and wait for the job to notify its completion.
> [1] https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui...
> Examples of using a series of commands in parallel w/ a wait at the end:
> http://stackoverflow.com/questions/19543139/bash-script-processing-comman...
> {code:title=spawns the 3 parallel steps, waits until #3 is done (2 seconds later) and returns the PID of the last one + its return code}
> echo "1" & echo 2 & (sleep 2;echo 3) & wait && echo $! $#
> {code}
> More discussion:
> {quote}
> [12:44:46 PM] Mickael Istria: I believe some parts would have to be turned into functions
> [12:54:41 PM] Mickael Istria: so, to hack the script, it could be just:
> * add && after the 1st rsync in each loop
> * add & after the last one
> * put a wait after the last loop
> * give the big piece of code to procede directly to bash
> {quote}
> After this job is done, releng would still have to "wire up" the new bits by updating composite*.xml and index.html pages, but that's considerably easier to do locally in a terminal, or even to script too. Rather than updating these files w/ sed, we could generate them from a template.
> And if we don't care about committing those changes back to github, we could even push them to the dl.jb.o and ds.jb.c servers directly as part of the above job.
> Scary, but much faster!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-21955) Server adapter: service details text is selectable (each line on its own)
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21955?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21955.
---------------------------------
Verified in Red Hat Developer Studio 10.0.0.Alpha1 B5264.
> Server adapter: service details text is selectable (each line on its own)
> -------------------------------------------------------------------------
>
> Key: JBIDE-21955
> URL: https://issues.jboss.org/browse/JBIDE-21955
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Jan Richter
> Assignee: Viacheslav Kabanovich
> Priority: Minor
> Labels: openshift_v3, server_adapter_wizard
> Fix For: 4.4.0.Alpha1
>
>
> One can select the values in the Service detail part of the wizard. The fun part is they are all independent and can be selected on their own.
> So once some line is selected, the only way to deselect it is to click inside it again - which places the annoying caret into the text.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-21004) Inconsistent upper casing in New Connection dialog
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21004?page=com.atlassian.jira.plugi... ]
Marián Labuda closed JBIDE-21004.
---------------------------------
Verified in Red Hat Developer Studio 10.0.0.Alpha1 B5264.
> Inconsistent upper casing in New Connection dialog
> --------------------------------------------------
>
> Key: JBIDE-21004
> URL: https://issues.jboss.org/browse/JBIDE-21004
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.CR1
> Reporter: Marián Labuda
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.4.0.Alpha1
>
>
> There are several places, where upper casing should be more consistent.
> Label for a default server checkbox is "Use default Server". I think better would be "Use default server"
> Secure storage checkbox label "Save Token" or "Save Password" followed by description in parenthesis "(could trigger secure storage)" could follow rest of the dialog. E.g. "Save token (could trigger secure storage)." and "Save password (could trigger secure storage)."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months