[JBoss JIRA] (JBIDE-19270) Unhandled event loop exception when opening Batch Job Configuration editor
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19270?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-19270:
-----------------------------------------------
[~snjeza], you explicitly fix exception in Section.onPaint(). Does that also helps with the other exception in my comment of 18/Feb/15?
> Unhandled event loop exception when opening Batch Job Configuration editor
> --------------------------------------------------------------------------
>
> Key: JBIDE-19270
> URL: https://issues.jboss.org/browse/JBIDE-19270
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch, upstream
> Affects Versions: 4.3.0.Alpha2
> Reporter: Alexey Kazakov
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.3.0.Alpha2
>
>
> 1. Close all Batch Job Configuration editors
> 2. Open any Batch Job Configuration editor (the Design tab should be opened by default, if not then open that tab and re-open the editor).
> 3. See the log:
> {code}
> java.lang.IllegalArgumentException: Argument not valid
> at org.eclipse.swt.SWT.error(SWT.java:4458)
> at org.eclipse.swt.SWT.error(SWT.java:4392)
> at org.eclipse.swt.SWT.error(SWT.java:4363)
> at org.eclipse.swt.graphics.Image.init(Image.java:1294)
> at org.eclipse.swt.graphics.Image.<init>(Image.java:200)
> at org.eclipse.ui.forms.widgets.Section.onPaint(Section.java:344)
> at org.eclipse.ui.forms.widgets.ExpandableComposite$1.paintControl(ExpandableComposite.java:561)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4480)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1413)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1437)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1422)
> at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3212)
> at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:171)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2085)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5563)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4712)
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9174)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._gdk_window_process_all_updates(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gdk_window_process_all_updates(OS.java:5980)
> at org.eclipse.swt.widgets.Display.update(Display.java:4665)
> at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3844)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3415)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:648)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:592)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19270) Unhandled event loop exception when opening Batch Job Configuration editor
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19270?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-19270 at 3/23/15 4:23 PM:
------------------------------------------------------------------------
[~snjeza], you explicitly fix exception in Section.onPaint(). Does that also help with the other exception in my comment of 18/Feb/15?
was (Author: scabanovich):
[~snjeza], you explicitly fix exception in Section.onPaint(). Does that also helps with the other exception in my comment of 18/Feb/15?
> Unhandled event loop exception when opening Batch Job Configuration editor
> --------------------------------------------------------------------------
>
> Key: JBIDE-19270
> URL: https://issues.jboss.org/browse/JBIDE-19270
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch, upstream
> Affects Versions: 4.3.0.Alpha2
> Reporter: Alexey Kazakov
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.3.0.Alpha2
>
>
> 1. Close all Batch Job Configuration editors
> 2. Open any Batch Job Configuration editor (the Design tab should be opened by default, if not then open that tab and re-open the editor).
> 3. See the log:
> {code}
> java.lang.IllegalArgumentException: Argument not valid
> at org.eclipse.swt.SWT.error(SWT.java:4458)
> at org.eclipse.swt.SWT.error(SWT.java:4392)
> at org.eclipse.swt.SWT.error(SWT.java:4363)
> at org.eclipse.swt.graphics.Image.init(Image.java:1294)
> at org.eclipse.swt.graphics.Image.<init>(Image.java:200)
> at org.eclipse.ui.forms.widgets.Section.onPaint(Section.java:344)
> at org.eclipse.ui.forms.widgets.ExpandableComposite$1.paintControl(ExpandableComposite.java:561)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4480)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1413)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1437)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1422)
> at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3212)
> at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:171)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2085)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5563)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4712)
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9174)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._gdk_window_process_all_updates(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gdk_window_process_all_updates(OS.java:5980)
> at org.eclipse.swt.widgets.Display.update(Display.java:4665)
> at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3844)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3415)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:648)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:592)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBDS-3374) Remove org.eclipse.cvs feature from JBDS
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3374?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3374:
-------------------------------------------
cvs comit wizard is the #23rd most used wizard.
cvs checkout is the #90th wizard
and we got ~1460 registered wizards.
egit wizards for push/clone/branch are in the #30th most.
So I would consider cvs as a well documented and often used component.
> Remove org.eclipse.cvs feature from JBDS
> ----------------------------------------
>
> Key: JBDS-3374
> URL: https://issues.jboss.org/browse/JBDS-3374
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Components: installer
> Affects Versions: 9.0.0.Alpha1
> Reporter: Fred Bricon
>
> com.jboss.devstudio.core.feature/feature.xml declares
> {quote}
> <import feature="org.eclipse.cvs"/>
> {quote}
> I can't see any reason why we'd do that in 2015.
> Burr Sutter, Len DiMaggio, Max Rydahl Andersen : is there any client requirement about CVS support?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19270) Unhandled event loop exception when opening Batch Job Configuration editor
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19270?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-19270:
---------------------------------------
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=460286#c5
> Unhandled event loop exception when opening Batch Job Configuration editor
> --------------------------------------------------------------------------
>
> Key: JBIDE-19270
> URL: https://issues.jboss.org/browse/JBIDE-19270
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: batch, upstream
> Affects Versions: 4.3.0.Alpha2
> Reporter: Alexey Kazakov
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.3.0.Alpha2
>
>
> 1. Close all Batch Job Configuration editors
> 2. Open any Batch Job Configuration editor (the Design tab should be opened by default, if not then open that tab and re-open the editor).
> 3. See the log:
> {code}
> java.lang.IllegalArgumentException: Argument not valid
> at org.eclipse.swt.SWT.error(SWT.java:4458)
> at org.eclipse.swt.SWT.error(SWT.java:4392)
> at org.eclipse.swt.SWT.error(SWT.java:4363)
> at org.eclipse.swt.graphics.Image.init(Image.java:1294)
> at org.eclipse.swt.graphics.Image.<init>(Image.java:200)
> at org.eclipse.ui.forms.widgets.Section.onPaint(Section.java:344)
> at org.eclipse.ui.forms.widgets.ExpandableComposite$1.paintControl(ExpandableComposite.java:561)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:230)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4480)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1413)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1437)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1422)
> at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3212)
> at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:171)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2085)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5563)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4712)
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9174)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._gdk_window_process_all_updates(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gdk_window_process_all_updates(OS.java:5980)
> at org.eclipse.swt.widgets.Display.update(Display.java:4665)
> at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3844)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3415)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:648)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:592)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-18772:
------------------------------------
Please escape your \{ (with a \ ) so they don't break & become illegible in JIRA.
-----
Recursive rsync is a nice idea but to allow renaming from source folder (repository) to target folder ($\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/all/repo/), we'd have to copy the output in the workspace FIRST, then push the relative path to the remote server:
{code}
mkdir -p $tmpdir/mars/snapshots/builds/$\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/all/repo
rsync -a ${project.build.directory}/repository/* $tmpdir/mars/snapshots/builds/$\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/all/repo/
pushd $tmpdir
rsync -a --relative mars/snapshots/builds/$\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/all/repo/ user@remote:/jbosstools/'
popd
{code}
Recursive sftp does the same thing but doesn't require lots of space on disk. I suppose we could move instead of copying, but then the expected build output in /target/repository/ won't be there so it's harder to diagnose build problems... much like you don't like having Jenkins assume all the github sources are in $\{WORKSPACE}/sources, I don't like having a workspace that's organized differently for Jenkins vs. local builds.
Aside: in your example you had both "updates" and "builds" in the same path. That should never happen -- we are no longer mixing concerns with JBDS-3208 reorg. I'm sure that was just a copy&paste error, but I wanted to make sure that was clearly stated.
-----
re: copy of the build log, I will poll jbosstools-dev and ask if anyone wants that kept. This step is skipped if there's no JOB_NAME (eg., for local builds)
-----
* create a symlink from this latest $\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER} folder to $\{JOB_NAME}/latest/
* create a composite site in $\{JOB_NAME}/ of all the */all/repo/ folders, and purge old published folders older than 2 days old
The first step is just one line of code:
{code}
# if TARGET_PATH contains a BUILD_ID-B# folder,
# create symlink: jbosstools-build-sites.aggregate.earlyaccess-site_master/latest -> jbosstools-build-sites.aggregate.earlyaccess-site_master/${BUILD_ID}-B${BUILD_NUMBER}
if [[ ${TARGET_PATH/${BUILD_ID}-B${BUILD_NUMBER}} != ${TARGET_PATH} ]]; then
pushd $tmpdir >/dev/null; ln -s ${BUILD_ID}-B${BUILD_NUMBER} latest; rsync --protocol=28 -l latest ${DESTINATION}/${PARENT_PATH}/; rm -f latest; popd >/dev/null
fi
{code}
The second step is just a simple call to jbosstools-cleanup.sh with a specific folder path to clean.
Are you suggesting that we should have a deploy phase mojo that JUST does the copy of bits, and all these other steps would be a SECOND step in the job?
If so... what do we gain by splitting rsync.sh into a simply rsync call + some additional publishing/linking/cleanup? Surely the act of publishing should include the creation of composite*.xml and purging of week-only nigthlies, too?
-----
* create a link to the published content from within the Jenkins job's BUILD_DESCRIPTION [not required but nice to have]
You want a separate shell script to just do this? All it does is produce a single link to the output build (if $\{URL} is specified):
{code}
# given TARGET_PATH=/downloads_htdocs/tools/mars/snapshots/builds/jbosstools-build-sites.aggregate.earlyaccess-site_master/2015-03-06_17-58-07-B13/all/repo/
PARENT_PATH=$(echo $TARGET_PATH | sed -e "s#/\?downloads_htdocs/tools/##" -e "s#/\?all/repo/\?##" -e "s#/\$##" -e "s#^/##" -e "s#\(.\+\)/[^/]\+#\1#")
LAST_SEGMENT=$(echo $TARGET_PATH | sed -e "s#/\?downloads_htdocs/tools/##" -e "s#/\?all/repo/\?##" -e "s#/\$##" -e "s#^/##" -e "s#\(.\+\)/\([^/]\+\)#\2#")
BUILD_DESCRIPTION='<li><a href='${URL}'/'${PARENT_PATH}'/'${LAST_SEGMENT}'>'${LAST_SEGMENT}'</a></li>'
{code}
We used to have a much more complex BUILD_DESCRIPTION with links to TPs used in the build, test coverage results, etc. I stripped it down to a single link to the build output folder. Is that STILL too much information?
-----
What I'm hearing is that Max feels that the deploy phase should ONLY copy bits from the Jenkins workspace to somewhere on some server (sftp path entirely configurable). But to make those jobs Just Work for publishing into the composites/aggregates/downstream, we at least need the latest/ symlinks to be created during the same build (so that they don't point to outdated content) and we need automated cleanup (so that we don't blow up download.jboss.org w/ 1000s of CI builds).
-----
Re: the Take 2 solution... that looks OK but ONLY for project builds. Aggregate builds need TWO pushes [one into builds, one into updates], and the matrix job that handles webtools/central/EA must make sure it's passing in the correct paths, since the JOB_NAME doesn't include the name of the matrix config (eg., webtools-site, central-site, earlyaccess-site).
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-18772 at 3/23/15 3:23 PM:
-------------------------------------------------------------
I really really like the idea of mvn deploy being nothing but the rsync call. But I understand we so far do much more in rsync.sh, but let me try and see which are *Actually* needed.
* ensure that the full target path actually exists before trying to rsync there
Could that not be solved by using one of the tips suggested here: http://stackoverflow.com/a/22908437/71208
'rsync -a --relative $\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/all/repo/ user@remote:/jbosstools/updates/mars/snapshots/builds'
meaning it will fail if the snapshots/builds dir does not exist (which seems like a *good* thing that it will fail) and it will create the --relative part.
* create a symlink from this latest $\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER} folder to $\{JOB_NAME}/latest/
* create a composite site in $\{JOB_NAME}/ of all the */all/repo/ folders, and purge old published folders older than 2 days old
This to me sounds like a thing that could be called when the jenkins jobs are done and kept outside of the responsibility of the component pom's ?
* create a copy of the build log in the $\{JOB_NAME}/$\{BUILD_ID}-B$\{BUILD_NUMBER}/logs/ folder
is this one really needed ? could it be done in the separate job from above ?
* create a link to the published content from within the Jenkins job's BUILD_DESCRIPTION [not required but nice to have]
That seems like the wrong place to have it anyway the job itself would know where it is anyway since it passes in all the subpieces of the url.
The advantage of splitting this up is that the pom.xml in the project can deploy to anywhere - without having full magic system access to its destination - leaving the 'log file cleanup/syncing' etc. to a a jenkins job outside of the component build.
This seems to be a better split of tasks/responsibilities IMO.
WDYT ?
was (Author: maxandersen):
I really really like the idea of mvn deploy being nothing but the rsync call. But I understand we so far do much more in rsync.sh, but let me try and see which are *Actually* needed.
* ensure that the full target path actually exists before trying to rsync there
Could that not be solved by using one of the tips suggested here: http://stackoverflow.com/a/22908437/71208
'rsync -a --relative ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/all/repo/ user@remote:/jbosstools/updates/mars/snapshots/builds'
meaning it will fail if the snapshots/builds dir does not exist (which seems like a *good* thing that it will fail) and it will create the --relative part.
* create a symlink from this latest ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER} folder to ${JOB_NAME}/latest/
* create a composite site in ${JOB_NAME}/ of all the */all/repo/ folders, and purge old published folders older than 2 days old
This to me sounds like a thing that could be called when the jenkins jobs are done and kept outside of the responsibility of the component pom's ?
* create a copy of the build log in the ${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/logs/ folder
is this one really needed ? could it be done in the separate job from above ?
* create a link to the published content from within the Jenkins job's BUILD_DESCRIPTION [not required but nice to have]
That seems like the wrong place to have it anyway the job itself would know where it is anyway since it passes in all the subpieces of the url.
The advantage of splitting this up is that the pom.xml in the project can deploy to anywhere - without having full magic system access to its destination - leaving the 'log file cleanup/syncing' etc. to a a jenkins job outside of the component build.
This seems to be a better split of tasks/responsibilities IMO.
WDYT ?
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19479) Make sure we support DeltaSpike-1.3.0
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19479?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-19479:
-----------------------------------------------
The new release does not introduce new extensions, nor changes to existing extensions that would affect there support in JBoss Tools. The pull request only switches DeltaSpike libraries used in tests to the last version.
> Make sure we support DeltaSpike-1.3.0
> -------------------------------------
>
> Key: JBIDE-19479
> URL: https://issues.jboss.org/browse/JBIDE-19479
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cdi-extensions
> Affects Versions: 4.3.0.Alpha2
> Reporter: Alexey Kazakov
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Alpha2
>
>
> DeltaSpike-1.3.0 has been released. We should make sure we don't have anything broken in our DeltaSpike support for this release. We also should switch our tests to 1.3.0.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-18772) Include publish.sh in parent pom as versioned maven dependency
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18772:
----------------------------------------
Take 2:
{code:xml}
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>unpack</goal>
</goals>
<phase>deploy</phase>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.jboss.tools.releng</groupId>
<artifactId>jbosstools-releng-publish</artifactId>
<version>4.3.0.Alpha2-SNAPSHOT</version>
<type>tar.gz</type>
<outputDirectory>${project.build.directory}/releng-scripts</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.3.2</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
<phase>deploy</phase>
<configuration>
<executable>${project.build.directory}/releng-scripts/publish/rsync.sh</executable>
<arguments>
<arg>-s</arg>
<arg>${project.build.directory}/repository</arg>
<arg>-t</arg>
<arg>mars/snapshots/builds/${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/all/repo/</arg>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
{code}
> Include publish.sh in parent pom as versioned maven dependency
> --------------------------------------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Fix For: 4.3.0.Alpha2
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (JBIDE-19497) Use Jetty 9 in TP
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19497?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19497:
----------------------------------------
Currently, Eclipse Mars M5 ships mainly 9.2.5 artifacts, required by the org.eclipse.help feature, and has a couple of bundles (.server and .xml) that are 9.2.3, required by org.eclipse.wst.server_adapters.feature. This relationship is an "include" one for a specific version of Jetty, there is no way we can replace it.
So if you want a newer version of jetty, you have to work with upstream projects (platform-ua and wtp) to have them raising their dependency on jetty before Mars. I don't know if those projects have already moved or planed to move to newer versions.
Or, if you prefer, we can rely on jetty 9.2.5 in JBT/JBDS. In such case, please edit the bug description. But even if we move to 9.2.5 now, there are chances that other projects move up before Mars.
> Use Jetty 9 in TP
> -----------------
>
> Key: JBIDE-19497
> URL: https://issues.jboss.org/browse/JBIDE-19497
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
>
> *Reason:* It seems like we are ready to move away from Jetty 8 and to use Jetty 9 in CordovaSim & LiveReload. We should update TP to include all Jetty 9 bundles
> *Project page/sources:* https://www.eclipse.org/jetty/
> *Version:* 9.2.10.v20150310
> *License and owner:* Eclipse.org
> *Original p2 repo:* http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.9.v20150224
> *JBoss mirror:* TODO
> *Include Sources:* Yes
> *Affected projects:* Livereload, Cordovasim
> *Include in JBDS:* Yes
> *Type of dependency:* distribution
> *List of bundles added/removed:*
> {code}
> TODO: suggested diff on the .target files/p2diff
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years