[JBoss JIRA] (JBIDE-15175) NPE in Simple Web Service Wizard
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15175?page=com.atlassian.jira.plugi... ]
Denis Golovin updated JBIDE-15175:
----------------------------------
Fix Version/s: 4.1.1.Alpha2
(was: 4.1.x)
> NPE in Simple Web Service Wizard
> --------------------------------
>
> Key: JBIDE-15175
> URL: https://issues.jboss.org/browse/JBIDE-15175
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.1.0.CR1
> Environment: JBT 4.1.0.CR1-v20130706-1344-B374
> Reporter: Vlado Pakan
> Fix For: 4.1.1.Alpha2
>
>
> 1. Create Java Project and select it in Package explorer
> 2. Use Package Explorer context menu to invoke New Simple Web Service Wizard
> ASSERT: Wizard is displaying warning: "The project has to be Dynamic Web
> Project" and Dynamic web project combo-box is empty
> 3. Click on JAX-RS (REST) radio button
> ASSERT/ERROR?: Warning "The project has to be Dynamic Web
> Project" has disappeared
> 4. Click on JAX-WS (WSDL based) radio button
> ERROR: Error appears in error log:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.tools.ws.ui.wizards.JBossWSAnnotatedClassWizardPage.validate(JBossWSAnnotatedClassWizardPage.java:699)
> at org.jboss.tools.ws.ui.wizards.JBossWSAnnotatedClassWizardPage.isPageComplete(JBossWSAnnotatedClassWizardPage.java:569)
> at org.jboss.tools.ws.ui.wizards.JBossWSAnnotatedClassWizardPage$2.widgetSelected(JBossWSAnnotatedClassWizardPage.java:130)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
> at org.eclipse.jface.window.Window.open(Window.java:802)
> at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:259)
> at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:279)
> at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290)
> at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:243)
> at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:224)
> at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
> at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:167)
> at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
> at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
> at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:213)
> at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:420)
> at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
> at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15483 at 9/25/13 1:25 PM:
-------------------------------------------------------------
With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-15482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... >=4903 *{color:red}AWAITING FREE SLAVE since 1:05pm{color}*
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
was (Author: nickboldt):
With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-15482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... >=4903 *{color:red}AWAITING FREE SLAVE{color}*
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15483:
------------------------------------
Bootstrapping the required content under staging/CI/JOB_NAME/BUILD_ID using this script:
{code}
# as hudson user
cd ~/STATIC/jbds/builds/staging
for d in `find . -maxdepth 1 -name jbosstools-\*_master | grep -v aggregate | sort`; do num=`echo $d/logs/201*`; num=${num/.txt/}; num=${num##*/}; \
echo "mkdir ${d##./}" | sftp $TOOLS/builds/staging/CI/; scpr $d/* $TOOLS/builds/staging/CI/${d##./}/${num}/; done
{code}
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15483 at 9/25/13 1:06 PM:
-------------------------------------------------------------
With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... >=4903 *{color:red}AWAITING FREE SLAVE{color}*
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
was (Author: nickboldt):
With the above script enabled in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and we can effectively deprecate the old builds.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15483 at 9/25/13 1:07 PM:
-------------------------------------------------------------
With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-15482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... >=4903 *{color:red}AWAITING FREE SLAVE{color}*
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
was (Author: nickboldt):
With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... >=4903 *{color:red}AWAITING FREE SLAVE{color}*
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-15483:
-------------------------------
Fix Version/s: 4.1.1.Beta1
4.2.0.Alpha1
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15483:
------------------------------------
With the above script enabled in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}
Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and we can effectively deprecate the old builds.
THEN I can consider rolling this out to the 4.1.x branch for Beta2.
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15482 at 9/25/13 12:54 PM:
--------------------------------------------------------------
Accidentally pushed the PR in too soon... so for now, while testing and giving people time to migrate, we have this:
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, JOB_NAME/BUILD_ID/all/repo/)
was (Author: nickboldt):
Accidentally pushed the PR in too soon... so for now, while testing and giving people time to migrate, we have this:
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (old way, BUILD_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publ... (new way, BUILD_NAME/TIMESTAMP/all/repo/)
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15483 at 9/25/13 12:52 PM:
--------------------------------------------------------------
Rather than using a template, I've just decided to generate the composite*.xml files from commandline input, so it can be tweaked more easily from within a Jenkins job.
Here's the script:
https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat...
Thus, we run it like this:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM <num builds to include, eg., 1 or 2> -NAME 'Site Name' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/path/goes/here/ -SITES http://download.jboss.org/jbosstools/updates/site/to/include1,http://down.... -JOBNAMES <job1,job2,job3,...>
{code}
Which for JBT 4.1 (keeping the latest 1 build for each component) would be:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 1 -NAME 'JBoss Tools - Core - Stable Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/4.1.x.kepler/ -SITES http://download.jboss.org/jbosstools/updates/stable/kepler/,http://downlo... -JOBNAMES jbosstools-aerogear_41,jbosstools-arquillian_41,jbosstools-base_41,jbosstools-birt_41,jbosstools-central_41,jbosstools-forge_41,jbosstools-hibernate_41,jbosstools-javaee_41,jbosstools-jst_41,jbosstools-livereload_41,jbosstools-openshift_41,jbosstools-portlet_41,jbosstools-server_41,jbosstools-vpe_41,jbosstools-webservices_41,openshift-java-client-master
{code}
and for the master branch, JBT 4.2 (keeping the latest 2 builds for each component, if available):
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 2 -NAME 'JBoss Tools - Core - Trunk Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/master/ -SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2... -JOBNAMES jbosstools-aerogear_master,jbosstools-arquillian_master,jbosstools-base_master,jbosstools-birt_master,jbosstools-central_master,jbosstools-forge_master,jbosstools-hibernate_master,jbosstools-javaee_master,jbosstools-jst_master,jbosstools-livereload_master,jbosstools-openshift_master,jbosstools-portlet_master,jbosstools-server_master,jbosstools-vpe_master,jbosstools-webservices_master,openshift-java-client-master
{code}
was (Author: nickboldt):
Rather than using a template, I've just decided to generate the composite*.xml files from commandline input, so it can be tweaked more easily from within a Jenkins job.
Here's the script:
https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat...
Thus, we run it like this:
{code}
Usage : ./generateCompositeStagingSiteMetadata.sh -NUM <num builds to include> -NAME 'Site Name' -JOBNAMES <job1,job2,job3,...> -SITES http://download.jboss.org/jbosstools/updates/site/to/include1,http://down....
{code}
Which for JBT 4.1 (keeping the latest 1 build for each component) would be:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 1 -NAME 'JBoss Tools - Core - Stable Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/4.1.x.kepler/ -SITES http://download.jboss.org/jbosstools/updates/stable/kepler/,http://downlo... -JOBNAMES jbosstools-aerogear_41,jbosstools-arquillian_41,jbosstools-base_41,jbosstools-birt_41,jbosstools-central_41,jbosstools-forge_41,jbosstools-hibernate_41,jbosstools-javaee_41,jbosstools-jst_41,jbosstools-livereload_41,jbosstools-openshift_41,jbosstools-portlet_41,jbosstools-server_41,jbosstools-vpe_41,jbosstools-webservices_41,openshift-java-client-master
{code}
and for the master branch, JBT 4.2 (keeping the latest 2 builds for each component, if available):
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 2 -NAME 'JBoss Tools - Core - Trunk Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/master/-SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2... -JOBNAMES jbosstools-aerogear_master,jbosstools-arquillian_master,jbosstools-base_master,jbosstools-birt_master,jbosstools-central_master,jbosstools-forge_master,jbosstools-hibernate_master,jbosstools-javaee_master,jbosstools-jst_master,jbosstools-livereload_master,jbosstools-openshift_master,jbosstools-portlet_master,jbosstools-server_master,jbosstools-vpe_master,jbosstools-webservices_master,openshift-java-client-master
{code}
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months