[JBoss JIRA] (JBDS-3208) reorg directories for consistency across JBT/JBDS
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3208:
-----------------------------
Description:
Be it resolved - we should reorg directories for consistency across JBT/JBDS:
{code}
download.jboss.org
<earlyaccess,updates,discovery>/mars
/snapshots [replace nightly]
/staging [rename content for QE, moves to development when approved]
/development
/stable (updates/mars/stable is a pointer back into updates/mars)
drop /integration (not used)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
and
{code}
devstudio.redhat.com
<earlyaccess,updates,discovery>/9.0
/snapshots
/staging
/development
/stable (updates/9.0/stable is a pointer back into updates/9.0)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112
This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2....
[2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
was:
reorg directories for consistency across JBT/JBDS:
{code}
download.jboss.org
<earlyaccess,updates,discovery>/mars
/snapshots [replace nightly]
/staging [rename content for QE, moves to development when approved]
/development
/stable (updates/mars/stable is a pointer back into updates/mars)
drop /integration (not used)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
and
{code}
devstudio.redhat.com
<earlyaccess,updates,discovery>/9.0
/snapshots
/staging
/development
/stable (updates/9.0/stable is a pointer back into updates/9.0)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
> reorg directories for consistency across JBT/JBDS
> -------------------------------------------------
>
> Key: JBDS-3208
> URL: https://issues.jboss.org/browse/JBDS-3208
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Be it resolved - we should reorg directories for consistency across JBT/JBDS:
> {code}
> download.jboss.org
> <earlyaccess,updates,discovery>/mars
> /snapshots [replace nightly]
> /staging [rename content for QE, moves to development when approved]
> /development
> /stable (updates/mars/stable is a pointer back into updates/mars)
> drop /integration (not used)
> builds/<jobname>/<buildid>
> builds/<jobname>/composite*.xml for last 2 builds
> targetplatforms/<type>/<version>
> {code}
> and
> {code}
> devstudio.redhat.com
> <earlyaccess,updates,discovery>/9.0
> /snapshots
> /staging
> /development
> /stable (updates/9.0/stable is a pointer back into updates/9.0)
> builds/<jobname>/<buildid>
> builds/<jobname>/composite*.xml for last 2 builds
> targetplatforms/<type>/<version>
> {code}
> Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112
> This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2....
> [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBDS-3208) reorg directories for consistency across JBT/JBDS
by Nick Boldt (JIRA)
Nick Boldt created JBDS-3208:
--------------------------------
Summary: reorg directories for consistency across JBT/JBDS
Key: JBDS-3208
URL: https://issues.jboss.org/browse/JBDS-3208
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: build
Affects Versions: 9.0.0.Alpha1
Reporter: Nick Boldt
Assignee: Nick Boldt
reorg directories for consistency across JBT/JBDS:
{code}
download.jboss.org
<earlyaccess,updates,discovery>/mars
/snapshots [replace nightly]
/staging [rename content for QE, moves to development when approved]
/development
/stable (updates/mars/stable is a pointer back into updates/mars)
drop /integration (not used)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
and
{code}
devstudio.redhat.com
<earlyaccess,updates,discovery>/9.0
/snapshots
/staging
/development
/stable (updates/9.0/stable is a pointer back into updates/9.0)
builds/<jobname>/<buildid>
builds/<jobname>/composite*.xml for last 2 builds
targetplatforms/<type>/<version>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18742) Decide whether to publish new aggregate by comparating it with last snapshot
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-18742:
-----------------------------------
Description:
Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
It's more or less just a matter of scripting
{code}
p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
if [[ -s p2diff_snapshot ]]; then
./publish.sh
fi
{code}
Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
was:
Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
It's more or less just a matter of scripting
{code}
p2diff file:/local/p2/repo http://download.jboss.org/builds/jbosstools-aggregate_master/repo > diff
if [ diff seems cool ]; then
./publish.sh
fi
{code}
Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
> Decide whether to publish new aggregate by comparating it with last snapshot
> ----------------------------------------------------------------------------
>
> Key: JBIDE-18742
> URL: https://issues.jboss.org/browse/JBIDE-18742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
>
> Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
> It's more or less just a matter of scripting
> {code}
> p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
> if [[ -s p2diff_snapshot ]]; then
> ./publish.sh
> fi
> {code}
> Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18742) Decide whether to publish new aggregate by comparating it with last snapshot
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-18742:
-----------------------------------
Description:
Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
It's more or less just a matter of scripting
{code:none}
p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
if [[ -s p2diff_snapshot ]]; then
./publish.sh
fi
{code}
Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
was:
Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
It's more or less just a matter of scripting
{code}
p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
if [[ -s p2diff_snapshot ]]; then
./publish.sh
fi
{code}
Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
> Decide whether to publish new aggregate by comparating it with last snapshot
> ----------------------------------------------------------------------------
>
> Key: JBIDE-18742
> URL: https://issues.jboss.org/browse/JBIDE-18742
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
>
> Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not.
> It's more or less just a matter of scripting
> {code:none}
> p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot
> if [[ -s p2diff_snapshot ]]; then
> ./publish.sh
> fi
> {code}
> Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-17632) Support rendering of JSF widgets in preview mode of VPE editor
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17632?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov resolved JBIDE-17632.
--------------------------------------------
Resolution: Done
On Face-2-Face it was decided that we will not reimplement JavaEE stuff made using xulrunner.
> Support rendering of JSF widgets in preview mode of VPE editor
> --------------------------------------------------------------
>
> Key: JBIDE-17632
> URL: https://issues.jboss.org/browse/JBIDE-17632
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: visual-page-editor-core
> Affects Versions: 4.2.0.Beta2
> Environment: Mac OS X Mavericks, Oracle JDK 7u60, Oracle JDK 8u5
> Reporter: Vineet Reynolds
> Assignee: Konstantin Marmalyukov
> Fix For: 4.3.x
>
> Attachments: PreviewMode-JBDS8.jpg, visual_page_editor.png
>
>
> JSF input widgets in XHTML files are rendered as plain text, when viewed in Visual mode of the JBoss Tools HTML editor.
> This is a side-effect of using tha WebKit engine in Mac, to perform the rendering:
> {noformat}
> kmarmaliykov: vineetr: Now everything is rendered using modern webkit engine. It works perfect for HTML5 pages but hasn't support jsf tags
> {noformat}
> This is being raised as a tracker issue for JBDS 8, since:
> {noformat}
> kmarmaliykov: vineetr: For JBDS8 the main goal was to provide good preview for html5 pages
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18741) Java EE 7 batch API missing from WildFly classpath container
by Valentin Baciu (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18741?page=com.atlassian.jira.plugi... ]
Valentin Baciu updated JBIDE-18741:
-----------------------------------
Description:
I recently upgraded to Eclipse Luna SR1 + JBoss Tools 4.2 and my workspace failed to build properly.
It appears that the javax.batch API is missing from the WildFly classpath container. The API is exposed by the javax.batch.api WildFly module (jboss-batch-api_1.0_spec-1.0.0.Final.jar).
As a workaround, I had to add the module via Preferences->Server->Runtime Environments->Default Classpath Entries.
was:
I recently upgraded to Eclipse Luna SR1 + JBoss Tools 4.2 and my workspace failed to build properly.
It appears that the javax.batch API is missing from the WildFly class path container. The API is exposed by the javax.batch.api WildFly module (jboss-batch-api_1.0_spec-1.0.0.Final.jar).
As a workaround, I had to add the module via Preferences->Server->Runtime Environments->Default Classpath Entries.
> Java EE 7 batch API missing from WildFly classpath container
> ------------------------------------------------------------
>
> Key: JBIDE-18741
> URL: https://issues.jboss.org/browse/JBIDE-18741
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Valentin Baciu
>
> I recently upgraded to Eclipse Luna SR1 + JBoss Tools 4.2 and my workspace failed to build properly.
> It appears that the javax.batch API is missing from the WildFly classpath container. The API is exposed by the javax.batch.api WildFly module (jboss-batch-api_1.0_spec-1.0.0.Final.jar).
> As a workaround, I had to add the module via Preferences->Server->Runtime Environments->Default Classpath Entries.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18741) Java EE 7 batch API missing from WildFly classpath container
by Valentin Baciu (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18741?page=com.atlassian.jira.plugi... ]
Valentin Baciu updated JBIDE-18741:
-----------------------------------
Summary: Java EE 7 batch API missing from WildFly classpath container (was: Java EE 7 batch API missing from WildFly class path container)
> Java EE 7 batch API missing from WildFly classpath container
> ------------------------------------------------------------
>
> Key: JBIDE-18741
> URL: https://issues.jboss.org/browse/JBIDE-18741
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Valentin Baciu
>
> I recently upgraded to Eclipse Luna SR1 + JBoss Tools 4.2 and my workspace failed to build properly.
> It appears that the javax.batch API is missing from the WildFly class path container. The API is exposed by the javax.batch.api WildFly module (jboss-batch-api_1.0_spec-1.0.0.Final.jar).
> As a workaround, I had to add the module via Preferences->Server->Runtime Environments->Default Classpath Entries.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18055) NullPionterException in VPE Preview Editor initialization
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18055?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-18055:
-------------------------------
Sprint: Sprint 20141112, Sprint to CR1 Release, Sprint 20141113 (was: Sprint 20141112, Sprint to CR1 Release)
> NullPionterException in VPE Preview Editor initialization
> ---------------------------------------------------------
>
> Key: JBIDE-18055
> URL: https://issues.jboss.org/browse/JBIDE-18055
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: visual-page-editor-core
> Affects Versions: 4.2.0.Beta3
> Reporter: Denis Golovin
> Assignee: Konstantin Marmalyukov
> Priority: Minor
> Fix For: 4.3.0.Alpha1
>
>
> Exception below can happen sometimes in case re-sizing visual preview part while preview server serving the editor is not started yet.
> {code}java.lang.NullPointerException
> at org.jboss.tools.vpe.preview.core.server.VpvServer.getPort(VpvServer.java:66)
> at org.jboss.tools.vpe.preview.editor.VpvEditor.formRequestToServer(VpvEditor.java:503)
> at org.jboss.tools.vpe.preview.editor.VpvEditor.reload(VpvEditor.java:494)
> at org.jboss.tools.vpe.preview.editor.VpvEditorPart.updateVisualEditorVisibility(VpvEditorPart.java:769)
> at org.jboss.tools.vpe.preview.editor.VpvEditorPart$5.controlResized(VpvEditorPart.java:386)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:235)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4486)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1393)
> at org.eclipse.swt.widgets.Control.setBounds(Control.java:1042)
> at org.eclipse.swt.widgets.Composite.setBounds(Composite.java:1435)
> at org.eclipse.swt.widgets.Control.setBounds(Control.java:851)
> at org.eclipse.swt.custom.SashForm.onDragSash(SashForm.java:288)
> at org.eclipse.swt.custom.SashForm$1.handleEvent(SashForm.java:90)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4486)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
> at org.eclipse.swt.widgets.Widget.sendSelectionEvent(Widget.java:1526)
> at org.eclipse.swt.widgets.Sash.gtk_motion_notify_event(Sash.java:396)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2104)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:5510)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4700)
> 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:9074)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
> at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
> at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2473)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3439)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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.8#6338)
11 years, 4 months