[JBoss JIRA] (JBTIS-906) Detect and throw a known issue for SWITCHYARD-2882
by Andrej Podhradsky (JIRA)
Andrej Podhradsky created JBTIS-906:
---------------------------------------
Summary: Detect and throw a known issue for SWITCHYARD-2882
Key: JBTIS-906
URL: https://issues.jboss.org/browse/JBTIS-906
Project: JBoss Tools Integration Stack
Issue Type: Task
Components: QE, switchyard
Affects Versions: 4.3.1.Final
Reporter: Andrej Podhradsky
Assignee: Andrej Podhradsky
Detect and throw a known issue for SWITCHYARD-2882 in ProjectExplorerProjectCreationTest so that we can avoid errors such as
*Error Message*
The following errors occured during creating SY project:
Referenced file contains errors (jar:file:/home/jbossqa/workspace/jbdsis9x.test.switchyard/jdk/oraclejdk1.8/label/RHEL7/jbds-installer/jbdsis-9.nightly/target/jbdevstudio/studio/plugins/org.switchyard.tools.xsd_2.1.0.CI-v20160915-2107-B33.jar!/schema/sca-binding-ws-1.1-cd04-rev2.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
*Stacktrace*
{code}
java.lang.AssertionError: The following errors occured during creating SY project:
Referenced file contains errors (jar:file:/home/jbossqa/workspace/jbdsis9x.test.switchyard/jdk/oraclejdk1.8/label/RHEL7/jbds-installer/jbdsis-9.nightly/target/jbdevstudio/studio/plugins/org.switchyard.tools.xsd_2.1.0.CI-v20160915-2107-B33.jar!/schema/sca-binding-ws-1.1-cd04-rev2.xsd). For more information, right click on the message in the Problems View and select "Show Details..."
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.tools.switchyard.ui.bot.test.ProjectExplorerProjectCreationTest.createProjectWithComponentsTest(ProjectExplorerProjectCreationTest.java:279)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-19188) Lot of exceptions after renaming project
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19188?page=com.atlassian.jira.plugi... ]
Rastislav Wagner commented on JBIDE-19188:
------------------------------------------
[~koen.aers] I tried with Devstudio 10.2.0.AM1-v20160921-0614-B6069 (latest nightly) and it is reproducible. Steps are the same as written in JIRA.
1. import Java EE project from central
2. right click on project -> Refactor -> Rename..
3. change name, hit OK
4. check error log for errors
> Lot of exceptions after renaming project
> ----------------------------------------
>
> Key: JBIDE-19188
> URL: https://issues.jboss.org/browse/JBIDE-19188
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.2.2.Final
> Reporter: Rastislav Wagner
> Assignee: Koen Aers
> Fix For: 4.4.2.AM1
>
>
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4454)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateClasspathEntries(HibernateRefactoringUtil.java:303)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateConsoleConfig(HibernateRefactoringUtil.java:226)
> at org.hibernate.eclipse.launch.core.refactoring.LaunchConfigurationResourceNameChange.perform(LaunchConfigurationResourceNameChange.java:102)
> at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
> at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
> {code}
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4454)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateClasspathEntries(HibernateRefactoringUtil.java:303)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateConsoleConfig(HibernateRefactoringUtil.java:226)
> at org.hibernate.eclipse.launch.core.refactoring.LaunchConfigurationResourceNameChange.perform(LaunchConfigurationResourceNameChange.java:102)
> at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
> at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
> {code}
> {code}
> java.lang.IndexOutOfBoundsException: Index: 0
> at java.util.Collections$EmptyList.get(Collections.java:4454)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateClasspathEntries(HibernateRefactoringUtil.java:303)
> at org.hibernate.eclipse.launch.core.refactoring.HibernateRefactoringUtil.updateConsoleConfig(HibernateRefactoringUtil.java:226)
> at org.hibernate.eclipse.launch.core.refactoring.LaunchConfigurationResourceNameChange.perform(LaunchConfigurationResourceNameChange.java:102)
> at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
> at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
> at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:218)
> at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
> at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
> {code}
> {code}
> org.eclipse.core.internal.resources.ResourceException: Resource '/jboss-javaee6-webapp' does not exist.
> at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:341)
> at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:215)
> at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:147)
> at org.eclipse.core.internal.resources.Resource.checkAccessibleAndLocal(Resource.java:221)
> at org.eclipse.core.internal.resources.Resource.getPersistentProperty(Resource.java:1204)
> at org.hibernate.eclipse.utils.HibernateEclipseUtils.getUserOverrideDefaultCatalog(HibernateEclipseUtils.java:72)
> at org.hibernate.eclipse.console.EclipseLaunchConsoleConfigurationPreferences.getProjectOverrides(EclipseLaunchConsoleConfigurationPreferences.java:239)
> at org.hibernate.eclipse.console.EclipseLaunchConsoleConfigurationPreferences.getProperties(EclipseLaunchConsoleConfigurationPreferences.java:166)
> at org.jboss.tools.hibernate.jpt.core.internal.HibernateJpaProject.getDefaultCatalog(HibernateJpaProject.java:175)
> at org.eclipse.jpt.jpa.core.internal.context.persistence.AbstractPersistenceUnit.buildDefaultCatalog(AbstractPersistenceUnit.java:1368)
> at org.eclipse.jpt.jpa.core.internal.context.persistence.AbstractPersistenceUnit.updatePersistenceUnitMetadata(AbstractPersistenceUnit.java:1421)
> at org.eclipse.jpt.jpa.core.internal.context.persistence.AbstractPersistenceUnit.update(AbstractPersistenceUnit.java:303)
> at org.jboss.tools.hibernate.jpt.core.internal.context.HibernatePersistenceUnit.update(HibernatePersistenceUnit.java:95)
> at org.eclipse.jpt.jpa.core.internal.context.AbstractJpaContextModel.updateModels(AbstractJpaContextModel.java:73)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.persistence.GenericPersistence.update(GenericPersistence.java:75)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.persistence.GenericPersistenceXml.syncPersistence(GenericPersistenceXml.java:140)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.persistence.GenericPersistenceXml.updatePersistence(GenericPersistenceXml.java:97)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.persistence.GenericPersistenceXml.update(GenericPersistenceXml.java:93)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.GenericContextRoot.syncPersistenceXml(GenericContextRoot.java:128)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.GenericContextRoot.updatePersistenceXml(GenericContextRoot.java:162)
> at org.eclipse.jpt.jpa.core.internal.jpa1.context.GenericContextRoot.update(GenericContextRoot.java:78)
> at org.eclipse.jpt.jpa.core.internal.AbstractJpaProject.update(AbstractJpaProject.java:1994)
> at org.eclipse.jpt.jpa.core.internal.AbstractJpaProject$UpdateJobCommand.execute(AbstractJpaProject.java:1981)
> at org.eclipse.jpt.common.core.internal.utility.command.RepeatingJobCommandWrapper.executeCommand(RepeatingJobCommandWrapper.java:207)
> at org.eclipse.jpt.common.core.internal.utility.command.NotifyingRepeatingJobCommandWrapper.executeCommand(NotifyingRepeatingJobCommandWrapper.java:68)
> at org.eclipse.jpt.common.core.internal.utility.command.RepeatingJobCommandWrapper.execute_(RepeatingJobCommandWrapper.java:192)
> at org.eclipse.jpt.common.core.internal.utility.command.RepeatingJobCommandWrapper$StartJobCommand.execute(RepeatingJobCommandWrapper.java:172)
> at org.eclipse.jpt.common.core.internal.utility.command.DefaultJobCommandContext.execute(DefaultJobCommandContext.java:38)
> at org.eclipse.jpt.common.core.internal.utility.command.RepeatingJobCommandWrapper.executeStartCommand(RepeatingJobCommandWrapper.java:157)
> at org.eclipse.jpt.common.core.internal.utility.command.RepeatingJobCommandWrapper.execute(RepeatingJobCommandWrapper.java:147)
> at org.eclipse.jpt.jpa.core.internal.AbstractJpaProject.update(AbstractJpaProject.java:1973)
> at org.eclipse.jpt.jpa.core.internal.AbstractJpaProject.initializeContextModel(AbstractJpaProject.java:303)
> at org.eclipse.jpt.jpa.core.internal.AbstractJpaProject.<init>(AbstractJpaProject.java:264)
> at org.jboss.tools.hibernate.jpt.core.internal.HibernateJpaProject.<init>(HibernateJpaProject.java:71)
> at org.jboss.tools.hibernate.jpt.core.internal.HibernateAbstractJpaFactory.buildJpaProject(HibernateAbstractJpaFactory.java:107)
> at org.jboss.tools.hibernate.jpt.core.internal.jpa2.HibernateJpaFactory2_0.buildJpaProject(HibernateJpaFactory2_0.java:89)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager.buildJpaProject(InternalJpaProjectManager.java:647)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager.buildJpaProject(InternalJpaProjectManager.java:635)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager.buildJpaProject(InternalJpaProjectManager.java:628)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager.addJpaProject(InternalJpaProjectManager.java:609)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager.checkForJpaFacetTransition_(InternalJpaProjectManager.java:846)
> at org.eclipse.jpt.jpa.core.internal.InternalJpaProjectManager$FacetFileChangeEventHandlerCommand.execute(InternalJpaProjectManager.java:836)
> at org.eclipse.jpt.common.core.internal.utility.command.CommandJobCommandAdapter.execute(CommandJobCommandAdapter.java:50)
> at org.eclipse.jpt.common.core.internal.utility.command.JobCommandJob.run(JobCommandJob.java:42)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
> and much more..
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTIS-905) Drools - PerspectiveTest is failing on Neon
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-905?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBTIS-905:
-----------------------------------------
Note that jBPM3 was removed in Neon
> Drools - PerspectiveTest is failing on Neon
> -------------------------------------------
>
> Key: JBTIS-905
> URL: https://issues.jboss.org/browse/JBTIS-905
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: drools/ jBPM, QE
> Affects Versions: 4.4.0.Alpha1
> Reporter: Andrej Podhradsky
> Assignee: Tomas David
> Fix For: 4.4.0.Alpha1
>
>
> *Error Message*
> Perspective jBPM isn't available
> *Stacktrace*
> {code}
> org.jboss.reddeer.eclipse.exception.EclipseLayerException: Perspective jBPM isn't available
> at org.jboss.reddeer.eclipse.ui.perspectives.AbstractPerspective.<init>(AbstractPerspective.java:41)
> at org.jboss.tools.drools.reddeer.perspective.JbpmPerspective.<init>(JbpmPerspective.java:11)
> at org.jboss.tools.drools.ui.bot.test.smoke.PerspectiveTest.openJbpmPerspectiveTest(PerspectiveTest.java:25)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTIS-905) Drools - PerspectiveTest is failing on Neon
by Andrej Podhradsky (JIRA)
Andrej Podhradsky created JBTIS-905:
---------------------------------------
Summary: Drools - PerspectiveTest is failing on Neon
Key: JBTIS-905
URL: https://issues.jboss.org/browse/JBTIS-905
Project: JBoss Tools Integration Stack
Issue Type: Bug
Components: drools/ jBPM, QE
Affects Versions: 4.4.0.Alpha1
Reporter: Andrej Podhradsky
Assignee: Tomas David
Fix For: 4.4.0.Alpha1
Error Message
Perspective jBPM isn't available
Stacktrace
{code}
org.jboss.reddeer.eclipse.exception.EclipseLayerException: Perspective jBPM isn't available
at org.jboss.reddeer.eclipse.ui.perspectives.AbstractPerspective.<init>(AbstractPerspective.java:41)
at org.jboss.tools.drools.reddeer.perspective.JbpmPerspective.<init>(JbpmPerspective.java:11)
at org.jboss.tools.drools.ui.bot.test.smoke.PerspectiveTest.openJbpmPerspectiveTest(PerspectiveTest.java:25)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTIS-905) Drools - PerspectiveTest is failing on Neon
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-905?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky updated JBTIS-905:
------------------------------------
Description:
*Error Message*
Perspective jBPM isn't available
*Stacktrace*
{code}
org.jboss.reddeer.eclipse.exception.EclipseLayerException: Perspective jBPM isn't available
at org.jboss.reddeer.eclipse.ui.perspectives.AbstractPerspective.<init>(AbstractPerspective.java:41)
at org.jboss.tools.drools.reddeer.perspective.JbpmPerspective.<init>(JbpmPerspective.java:11)
at org.jboss.tools.drools.ui.bot.test.smoke.PerspectiveTest.openJbpmPerspectiveTest(PerspectiveTest.java:25)
{code}
was:
Error Message
Perspective jBPM isn't available
Stacktrace
{code}
org.jboss.reddeer.eclipse.exception.EclipseLayerException: Perspective jBPM isn't available
at org.jboss.reddeer.eclipse.ui.perspectives.AbstractPerspective.<init>(AbstractPerspective.java:41)
at org.jboss.tools.drools.reddeer.perspective.JbpmPerspective.<init>(JbpmPerspective.java:11)
at org.jboss.tools.drools.ui.bot.test.smoke.PerspectiveTest.openJbpmPerspectiveTest(PerspectiveTest.java:25)
{code}
> Drools - PerspectiveTest is failing on Neon
> -------------------------------------------
>
> Key: JBTIS-905
> URL: https://issues.jboss.org/browse/JBTIS-905
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: drools/ jBPM, QE
> Affects Versions: 4.4.0.Alpha1
> Reporter: Andrej Podhradsky
> Assignee: Tomas David
> Fix For: 4.4.0.Alpha1
>
>
> *Error Message*
> Perspective jBPM isn't available
> *Stacktrace*
> {code}
> org.jboss.reddeer.eclipse.exception.EclipseLayerException: Perspective jBPM isn't available
> at org.jboss.reddeer.eclipse.ui.perspectives.AbstractPerspective.<init>(AbstractPerspective.java:41)
> at org.jboss.tools.drools.reddeer.perspective.JbpmPerspective.<init>(JbpmPerspective.java:11)
> at org.jboss.tools.drools.ui.bot.test.smoke.PerspectiveTest.openJbpmPerspectiveTest(PerspectiveTest.java:25)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBDS-4014) Track rh-eclipse46-devstudio-*.rpm version usage
by Alexander Kurtakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-4014?page=com.atlassian.jira.plugin.... ]
Alexander Kurtakov commented on JBDS-4014:
------------------------------------------
Not yet. Fully occupied with SWT work for now.
> Track rh-eclipse46-devstudio-*.rpm version usage
> ------------------------------------------------
>
> Key: JBDS-4014
> URL: https://issues.jboss.org/browse/JBDS-4014
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Feature Request
> Components: usage
> Reporter: Alexey Kazakov
> Assignee: Alexey Kazakov
> Priority: Critical
> Fix For: 10.2.0.AM1
>
>
> We need to distinguish the following use cases:
> 1) Devstudio installed via RPM
> 2) Devstudio installed via P2 but on top of the "base" eclipse rpm
> 3) Devstudio installed traditionally (jar installer or p2)
> As a bonus we could want to track if the DTS + devstudio rpms were both installed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23206) build flag for always use current timestamp to assist QE in testing PRs
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23206?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23206:
------------------------------------
Please review this PR. If you don't like the "R" name for the profile, we could call it "rawblem, and invoke it with -Prawblem. Or we could use a parameter and enable it with -Dparam=value. Open to suggestions, though I like -PR for its simplicity and few keystrokes.
> build flag for always use current timestamp to assist QE in testing PRs
> -----------------------------------------------------------------------
>
> Key: JBIDE-23206
> URL: https://issues.jboss.org/browse/JBIDE-23206
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.4.2.AM1
> Reporter: Rob Stryker
> Assignee: Nick Boldt
>
> In the case where a PR is not rebased against master constantly, QE is blocked from testing it under two situations:
> 1) The PR job has produced a site. QE installs most recent jbt, then tries to install the PR site. This fails because the PR site is older than the nightly build.
> 2) The QE rep checks out the PR and tries to build locally. The timestamps match the change date (ie the date the PR was last changed), which is still older than the nightly build.
> In both situations, QE cannot install a locally-built or PR-built site on top of a more recent nightly build of JBT. We cannot expect QE to rebase and (if required) merge / change code.
> The best bet here is to simply add a flag QE can use when building locally to always use current timestamp, to ensure locally built unit is always 'newest'.
> We then document that flag in devdoc for QE and make it part of their standard workflow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23206) build flag for always use current timestamp to assist QE in testing PRs
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23206?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-23206 at 9/20/16 9:08 PM:
-------------------------------------------------------------
PR: https://github.com/jbosstools/jbosstools-build/pull/232
To test this out:
1. clone the jbosstools-build project and build the parent pom with this PR applied: https://github.com/jbosstools/jbosstools-build/pull/232
2. clone jbosstools-openshift, and build from master. observe the timestamps of openshift.client plugin and openshift.feature in jbosstools-openshift/site/target/repository/
3. apply this PR https://github.com/jbosstools/jbosstools-openshift/pull/1312 and build again. observe the timestamps of openshift.client plugin and openshift.feature.
4. NOW... using the new R profile in parent pom ( https://github.com/jbosstools/jbosstools-build/pull/232 ) rebuild openshift:
{code}mvn clean install -PR{code}
5. observe that ALL the features and plugins in jbosstools-openshift/site/target/repository/ have the timestamp of when you started the latest build, in UTC (GMT+0).
was (Author: nickboldt):
PR:
To test this out:
1. clone the jbosstools-build project and build the parent pom with this PR applied: https://github.com/jbosstools/jbosstools-build/pull/232
2. clone jbosstools-openshift, and build from master. observe the timestamps of openshift.client plugin and openshift.feature in jbosstools-openshift/site/target/repository/
3. apply this PR https://github.com/jbosstools/jbosstools-openshift/pull/1312 and build again. observe the timestamps of openshift.client plugin and openshift.feature.
4. NOW... using the new R profile in parent pom ( https://github.com/jbosstools/jbosstools-build/pull/232 ) rebuild openshift:
{code}mvn clean install -PR{code}
5. observe that ALL the features and plugins in jbosstools-openshift/site/target/repository/ have the timestamp of when you started the latest build, in UTC (GMT+0).
> build flag for always use current timestamp to assist QE in testing PRs
> -----------------------------------------------------------------------
>
> Key: JBIDE-23206
> URL: https://issues.jboss.org/browse/JBIDE-23206
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Affects Versions: 4.4.2.AM1
> Reporter: Rob Stryker
> Assignee: Nick Boldt
>
> In the case where a PR is not rebased against master constantly, QE is blocked from testing it under two situations:
> 1) The PR job has produced a site. QE installs most recent jbt, then tries to install the PR site. This fails because the PR site is older than the nightly build.
> 2) The QE rep checks out the PR and tries to build locally. The timestamps match the change date (ie the date the PR was last changed), which is still older than the nightly build.
> In both situations, QE cannot install a locally-built or PR-built site on top of a more recent nightly build of JBT. We cannot expect QE to rebase and (if required) merge / change code.
> The best bet here is to simply add a flag QE can use when building locally to always use current timestamp, to ensure locally built unit is always 'newest'.
> We then document that flag in devdoc for QE and make it part of their standard workflow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months