[JBoss JIRA] (JBIDE-22956) NullPointerException in InstallationChecker.getUnits
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22956?page=com.atlassian.jira.plugi... ]
Fred Bricon reassigned JBIDE-22956:
-----------------------------------
Fix Version/s: 4.4.1.AM3
Story Points: 1
Sprint: devex #118 July 2016
Affects Version/s: 4.4.0.Final
Assignee: Fred Bricon
> NullPointerException in InstallationChecker.getUnits
> ----------------------------------------------------
>
> Key: JBIDE-22956
> URL: https://issues.jboss.org/browse/JBIDE-22956
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.4.0.Final
> Reporter: Automated Error Reporting Bot
> Assignee: Fred Bricon
> Fix For: 4.4.1.AM3
>
>
> The following problem was reported via the automated error reporting:
> Message: Unhandled event loop exception
> {noformat}
> java.lang.NullPointerException: null
> at org.jboss.tools.central.installation.InstallationChecker.getUnits(InstallationChecker.java:104)
> at org.jboss.tools.central.installation.InstallationChecker.getEarlyAccessUnits(InstallationChecker.java:97)
> at org.jboss.tools.central.installation.InstallationChecker.hasEarlyAccess(InstallationChecker.java:90)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.updateEarlyAccess(GettingStartedHtmlPage.java:352)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.access$14(GettingStartedHtmlPage.java:350)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage$6$1.run(GettingStartedHtmlPage.java:335)
> at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:162)
> at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:154)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4155)
> {noformat}
> Bundles:
> | org.eclipse.core.jobs | 3.8.0.v20160509-0411 | 3.8.0.v20160509-0411 |
> | org.eclipse.e4.core.di | 1.6.0.v20160319-0612 | 1.6.0.v20160319-0612 |
> | org.eclipse.swt | 3.104.2.v20160212-1350 | 3.105.0.v20160603-0902 |
> | org.eclipse.ui | 3.107.0.v20150507-1945 | 3.108.0.v20160518-1929 |
> | org.jboss.tools.central | 2.0.1.Final-v20160401-1059-B103 | 2.1.1.v20160627-1309 |
> Operating Systems:
> | Linux | 3.16.0 | 4.5.7.fc24 |
> | MacOSX | 10.10.5 | 10.10.5 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/571dad77e4b08bd809...] for the latest data.
> Thank you for your assistance.
> Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22956) NullPointerException in InstallationChecker.getUnits
by Automated Error Reporting Bot (JIRA)
Automated Error Reporting Bot created JBIDE-22956:
-----------------------------------------------------
Summary: NullPointerException in InstallationChecker.getUnits
Key: JBIDE-22956
URL: https://issues.jboss.org/browse/JBIDE-22956
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: central
Reporter: Automated Error Reporting Bot
The following problem was reported via the automated error reporting:
Message: Unhandled event loop exception
{noformat}
java.lang.NullPointerException: null
at org.jboss.tools.central.installation.InstallationChecker.getUnits(InstallationChecker.java:104)
at org.jboss.tools.central.installation.InstallationChecker.getEarlyAccessUnits(InstallationChecker.java:97)
at org.jboss.tools.central.installation.InstallationChecker.hasEarlyAccess(InstallationChecker.java:90)
at org.jboss.tools.central.editors.GettingStartedHtmlPage.updateEarlyAccess(GettingStartedHtmlPage.java:352)
at org.jboss.tools.central.editors.GettingStartedHtmlPage.access$14(GettingStartedHtmlPage.java:350)
at org.jboss.tools.central.editors.GettingStartedHtmlPage$6$1.run(GettingStartedHtmlPage.java:335)
at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:162)
at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:154)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4155)
{noformat}
Bundles:
| org.eclipse.core.jobs | 3.8.0.v20160509-0411 | 3.8.0.v20160509-0411 |
| org.eclipse.e4.core.di | 1.6.0.v20160319-0612 | 1.6.0.v20160319-0612 |
| org.eclipse.swt | 3.104.2.v20160212-1350 | 3.105.0.v20160603-0902 |
| org.eclipse.ui | 3.107.0.v20150507-1945 | 3.108.0.v20160518-1929 |
| org.jboss.tools.central | 2.0.1.Final-v20160401-1059-B103 | 2.1.1.v20160627-1309 |
Operating Systems:
| Linux | 3.16.0 | 4.5.7.fc24 |
| MacOSX | 10.10.5 | 10.10.5 |
| Windows | 6.1.0 | 10.0.0 |
The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/571dad77e4b08bd809...] for the latest data.
Thank you for your assistance.
Your friendly error-reports-inbox.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 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:
-------------------------------
Fix Version/s: 4.4.1.AM3
(was: 4.4.x)
> 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.1.AM3
>
>
> 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, 8 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 2016, devex #116 June 2016, devex #118 July 2016 (was: devex #115 May 2016, devex #116 June 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.x
>
>
> 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, 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 Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22728?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22728:
------------------------------------
Having discussed this in more depth with Max last week, I'd like to try to implement his idea of creating PRs w/ the "smart commit message" of "JBIDE-#### #close" so that as each PR is merged the 17 JIRAs would be closed automatically. That would give us JIRAs to track the changes, AND reduce the overhead involved in managing them.
However, I've tested smart commits with JBDS JIRAs and so far they've not worked. [~maxandersen] do you know how to enable smart commits for JBDS JIRA? I'll do more testing with JBIDE JIRA in the meantime, but since we need a JBDS JIRA created for tracking root pom changes in devstudio, it would be great to use smart commits for that one too.
> 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-22305) automate process for fetching latest target platform mirrors
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22305:
------------------------------------
Unless we have more mirrors to fetch for 4.4.1, this need slips to 4.4.2 (when we will be fetching lots of mirrors for Neon.1).
> automate process for fetching latest target platform mirrors
> ------------------------------------------------------------
>
> Key: JBIDE-22305
> URL: https://issues.jboss.org/browse/JBIDE-22305
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform, updatesite, upstream
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: releasework
> Fix For: 4.4.x
>
> Attachments: git.diff.txt
>
>
> Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names.
> Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace.
> Thus for webtools we might simply define:
> webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do...
> and we'd end up with:
> http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8....
> * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr
> 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p...
> 2. when all children are done, a downstream job can runs TP update & validation against new .target files
> * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf...
> * parse that into a list of URLs
> * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files
> * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs
> * resulting edited .target files will remain in the workspace, and we can then run
> * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u...
> * when done if success:
> * ideally, generate a PR and attach link in email to jbosstools-dev@
> * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR
> * email should includes boilerplate text to send mail to list announcing new change for review
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22305:
-------------------------------
Fix Version/s: 4.4.x
(was: 4.4.1.Final)
> automate process for fetching latest target platform mirrors
> ------------------------------------------------------------
>
> Key: JBIDE-22305
> URL: https://issues.jboss.org/browse/JBIDE-22305
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform, updatesite, upstream
> Affects Versions: 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: releasework
> Fix For: 4.4.x
>
> Attachments: git.diff.txt
>
>
> Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names.
> Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace.
> Thus for webtools we might simply define:
> webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do...
> and we'd end up with:
> http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8....
> * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr
> 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p...
> 2. when all children are done, a downstream job can runs TP update & validation against new .target files
> * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf...
> * parse that into a list of URLs
> * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files
> * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs
> * resulting edited .target files will remain in the workspace, and we can then run
> * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u...
> * when done if success:
> * ideally, generate a PR and attach link in email to jbosstools-dev@
> * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR
> * email should includes boilerplate text to send mail to list announcing new change for review
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months