[JBoss JIRA] (JBIDE-13452) investigate removing JBT_VERSION, JBDS_VERSION from parent pom
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13452?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13452 at 3/24/13 12:22 PM:
--------------------------------------------------------------
JBT_VERSION is still used in these files:
*{color:red}
./jbosstools-build/parent/pom.xml
{color}*
{code}
<JBT_VERSION>4.1.0</JBT_VERSION>
{code}
Cleaned from these files:
*{color:green}
-./jbosstools-build-sites/aggregate/build.xml-
-./jbosstools-build-sites/aggregate/**/pom.xml-
-./jbosstools-build-sites/results/build.xml-
-./jbosstools-build-sites/results/pom.xml-
-./jbosstools-base/site/pom.xml-
-./jbosstools-server/site/pom.xml-
./jbosstools-javaee/site/pom.xml
{color}*
Meanwhile, JBDS_VERSION is set in product/pom.xml (devstudio SVN) and used in these files:
*{color:red}
./product/installer/build.xml
./product/installer/pom.xml
./product/results/build.xml
./product/results/index-earlyaccess-template.html
./product/results/index-internal-template.html
./product/results/index-local-template.html
./product/results/pom.xml
./product/site/build.xml
./product/site/pom.xml
./product-soa/site/build.xml
./product-soa/site/pom.xml
./product/sources/build.xml
./product/sources/pom.xml{color}*
was (Author: nickboldt):
JBT_VERSION is still used in these files:
*{color:red}
./jbosstools-build/parent/pom.xml
./jbosstools-javaee/site/pom.xml
{color}*
{code}
<JBT_VERSION>4.1.0</JBT_VERSION>
{code}
Cleaned from these files:
*{color:green}
-./jbosstools-build-sites/aggregate/build.xml-
-./jbosstools-build-sites/aggregate/**/pom.xml-
-./jbosstools-build-sites/results/build.xml-
-./jbosstools-build-sites/results/pom.xml-
-./jbosstools-base/site/pom.xml-
-./jbosstools-server/site/pom.xml-
{color}*
Meanwhile, JBDS_VERSION is set in product/pom.xml (devstudio SVN) and used in these files:
*{color:red}
./product/installer/build.xml
./product/installer/pom.xml
./product/results/build.xml
./product/results/index-earlyaccess-template.html
./product/results/index-internal-template.html
./product/results/index-local-template.html
./product/results/pom.xml
./product/site/build.xml
./product/site/pom.xml
./product-soa/site/build.xml
./product-soa/site/pom.xml
./product/sources/build.xml
./product/sources/pom.xml{color}*
> investigate removing JBT_VERSION, JBDS_VERSION from parent pom
> --------------------------------------------------------------
>
> Key: JBIDE-13452
> URL: https://issues.jboss.org/browse/JBIDE-13452
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, target-platform, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> investigate removing JBT_VERSION, JBDS_VERSION, and TARGET_PLATFORM_VERSION (min and max) from parent pom
> Can we switch to using dynamic maven variables like project.version instead?
> Moving forward, jobs will override/set the version of target platform used to build (min) and test (max), and developers will be required to decide when/if to move to a newer parent pom or target platform version(s) if needed. For projects that are released, jobs will run only when TP changes (ie., will watch the jbosstools-target-platforms repo for changes).
--
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
13 years
[JBoss JIRA] (JBIDE-13821) CI runs tests against minimum instead of maximum
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13821?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13821:
------------------------------------
To answer your question (asked in https://github.com/jbosstools/jbosstools-build/pull/77 ):
"I don't understand why anyone would need to set/override this property from external scripts. which usecase is that since there are only one tpc.version to set ?"
The value of the property is passed from Jenkins to jbosstools-build-sites/aggregate/build.xml via two poms (for the JBT core agg site and the webtools agg site poms) so that we can generate pretty HTML pages reporting on what was used to produce the build.
publish.sh also receives these Jenkins properties so that this information can be captured in log files and fed back to the Jenkins view, via the Build Description configuration in the jobs.
Because -Pmaximum is a shorthand way of setting the selected TP version to the default maximum, and we would rather explicitly state the version when building via Jenkins (so that as above we can capture the information in results.html, logs, and Build Description), I've removed it from the 4.1/7.0/master/trunk jobs. I've left it in the 4.0/6.0 jobs because I can't be arsed and because less changes in maintenance branch are better than more. As you say, it's better to change less there so as to ensure builds are more reproducible.
----
As to the statement above that "the old property has zero effect", that's NOW true, but yesterday was false because these files depended on it:
https://svn.jboss.org/repos/devstudio/trunk/hudson-jobs/cache/https/jenki...
https://svn.jboss.org/repos/devstudio/trunk/hudson-jobs/cache/https/jenki...
https://github.com/jbosstools/jbosstools-build-sites/tree/master/aggregate (pom.xml files and build.xml, indirectly)
Before stating that something is not used, you might want to grep through the code looking for references.
Anyway, I can now remove TARGET_PLATFORM_VERSION-maximum from the parent pom in favour of TARGET_PLATFORM_VERSION_MAXIMUM. I'll leave it in the 40x branch, since it doesn't hurt anything and again, less change there is good.
I will remove it from master as part of thhe further cleanup effort in JBIDE-13452.
> CI runs tests against minimum instead of maximum
> ------------------------------------------------
>
> Key: JBIDE-13821
> URL: https://issues.jboss.org/browse/JBIDE-13821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.0.x, 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> As Maven executions set a value for the TARGET_PLATFORM_VERSION value, this property is not overriden by the maximum profile.
> Maven order to set properties is
> # look a -D... to set property, if not found
> # look at active profiles to set property, if not found
> # look at default value of property to set it
> This makes that in mvn execution for tests, the TARGET_PLATFORM_VERSION is set to minimal is CI jobs, whereas with using the -Pmaximun profile, we expect maximum.
> This is a critical issue since it caused hours of confusions to debug on 4.0.x branch.
--
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
13 years
[JBoss JIRA] (JBIDE-13452) investigate removing JBT_VERSION, JBDS_VERSION from parent pom
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13452?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13452:
------------------------------------
* *TARGET_PLATFORM_VERSION-maximum* removed from job configs in DevStudio_Trunk and DevStudio_7.0.kepler view, in favour of *TARGET_PLATFORM_VERSION_MAXIMUM*.
* *TARGET_PLATFORM_VERSION-maximum* removed from aggregate/site/pom.xml and aggregate/webtools-site/pom.xml, in favour of *TARGET_PLATFORM_VERSION_MAXIMUM*.
> investigate removing JBT_VERSION, JBDS_VERSION from parent pom
> --------------------------------------------------------------
>
> Key: JBIDE-13452
> URL: https://issues.jboss.org/browse/JBIDE-13452
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng, target-platform, updatesite
> Affects Versions: 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> investigate removing JBT_VERSION, JBDS_VERSION, and TARGET_PLATFORM_VERSION (min and max) from parent pom
> Can we switch to using dynamic maven variables like project.version instead?
> Moving forward, jobs will override/set the version of target platform used to build (min) and test (max), and developers will be required to decide when/if to move to a newer parent pom or target platform version(s) if needed. For projects that are released, jobs will run only when TP changes (ie., will watch the jbosstools-target-platforms repo for changes).
--
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
13 years
[JBoss JIRA] (JBIDE-13826) Error is thrown when Weld Scan object is created again
by Jaroslav Jankovič (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13826?page=com.atlassian.jira.plugi... ]
Jaroslav Jankovič commented on JBIDE-13826:
-------------------------------------------
Can't it be fixed in 4.0.x branch as well?
> Error is thrown when Weld Scan object is created again
> ------------------------------------------------------
>
> Key: JBIDE-13826
> URL: https://issues.jboss.org/browse/JBIDE-13826
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: CDI
> Affects Versions: 4.0.1.Final
> Environment: JBDS 6.0.1.CR1a
> Reporter: Jaroslav Jankovič
> Assignee: Alexey Kazakov
> Fix For: 4.1.0.Alpha1
>
>
> STEP: create a weld scan object in CDI beans.xml editor
> STEP: try to create it again
> FAIL: option to create a weld scan object again is clickable. Once clicked, nothing happens and error is thrown into error log:
> {code}
> org.jboss.tools.common.model.XModelException: Cdi beans beans.xml already contains Scan.
> at org.jboss.tools.common.meta.action.impl.handlers.DefaultCreateHandler.addCreatedObject(DefaultCreateHandler.java:179)
> at org.jboss.tools.common.meta.action.impl.handlers.DefaultCreateHandler.addCreatedObject(DefaultCreateHandler.java:169)
> at org.jboss.tools.common.meta.action.impl.handlers.DefaultCreateHandler.addCreatedObject(DefaultCreateHandler.java:143)
> at org.jboss.tools.common.meta.action.impl.handlers.DefaultCreateHandler.executeHandler(DefaultCreateHandler.java:49)
> at org.jboss.tools.common.meta.action.impl.XActionImpl.executeHandler(XActionImpl.java:65)
> at org.jboss.tools.common.model.ui.action.XModelObjectAction.actionPerformed(XModelObjectAction.java:96)
> at org.jboss.tools.common.model.ui.action.XModelObjectAction$AL.widgetSelected(XModelObjectAction.java:131)
> 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:3705)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3326)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1049)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:939)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:79)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:587)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:542)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> 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:353)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
> 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:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1443)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1419)
> {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
13 years
[JBoss JIRA] (JBIDE-13821) CI runs tests against minimum instead of maximum
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13821?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-13821:
---------------------------------------------
I can see you closed the pullrequest but ignored my comments.
The old property has zero effect so use of it from external scripts are irrelevant so how about just removing it so no doubt/maintanence?
btw. changing this is in maintanence does not sound like a good idea to me since it will make build even less reproducible.
> CI runs tests against minimum instead of maximum
> ------------------------------------------------
>
> Key: JBIDE-13821
> URL: https://issues.jboss.org/browse/JBIDE-13821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.0.x, 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> As Maven executions set a value for the TARGET_PLATFORM_VERSION value, this property is not overriden by the maximum profile.
> Maven order to set properties is
> # look a -D... to set property, if not found
> # look at active profiles to set property, if not found
> # look at default value of property to set it
> This makes that in mvn execution for tests, the TARGET_PLATFORM_VERSION is set to minimal is CI jobs, whereas with using the -Pmaximun profile, we expect maximum.
> This is a critical issue since it caused hours of confusions to debug on 4.0.x branch.
--
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
13 years
[JBoss JIRA] (JBIDE-13821) CI runs tests against minimum instead of maximum
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13821?page=com.atlassian.jira.plugi... ]
Nick Boldt closed JBIDE-13821.
------------------------------
Resolution: Done
Closing again because already solved and committed and signed off by QE.
> CI runs tests against minimum instead of maximum
> ------------------------------------------------
>
> Key: JBIDE-13821
> URL: https://issues.jboss.org/browse/JBIDE-13821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.0.x, 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> As Maven executions set a value for the TARGET_PLATFORM_VERSION value, this property is not overriden by the maximum profile.
> Maven order to set properties is
> # look a -D... to set property, if not found
> # look at active profiles to set property, if not found
> # look at default value of property to set it
> This makes that in mvn execution for tests, the TARGET_PLATFORM_VERSION is set to minimal is CI jobs, whereas with using the -Pmaximun profile, we expect maximum.
> This is a critical issue since it caused hours of confusions to debug on 4.0.x branch.
--
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
13 years
[JBoss JIRA] (JBIDE-13821) CI runs tests against minimum instead of maximum
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13821?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13821:
------------------------------------
[~maxandersen] The jira title is "CI runs tests" not "CI test runs". It's about how the job uses the wrong target platform when running tests.
> CI runs tests against minimum instead of maximum
> ------------------------------------------------
>
> Key: JBIDE-13821
> URL: https://issues.jboss.org/browse/JBIDE-13821
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.0.x, 4.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Critical
> Fix For: 4.0.1.Final, 4.1.0.Alpha2
>
>
> As Maven executions set a value for the TARGET_PLATFORM_VERSION value, this property is not overriden by the maximum profile.
> Maven order to set properties is
> # look a -D... to set property, if not found
> # look at active profiles to set property, if not found
> # look at default value of property to set it
> This makes that in mvn execution for tests, the TARGET_PLATFORM_VERSION is set to minimal is CI jobs, whereas with using the -Pmaximun profile, we expect maximum.
> This is a critical issue since it caused hours of confusions to debug on 4.0.x branch.
--
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
13 years
[JBoss JIRA] (JBIDE-13818) openshift-java-client: cannot restart stopped application (WATCHER ISSUE)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13818?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on JBIDE-13818:
-------------------------------------------------
openshift-github-bot <openshift-github-bot(a)redhat.com> made a comment on [bug 923369|https://bugzilla.redhat.com/show_bug.cgi?id=923369]
Commit pushed to master at https://github.com/openshift/origin-server
https://github.com/openshift/origin-server/commit/4f5f210aae55c874d443553...
Bug 923369
> openshift-java-client: cannot restart stopped application (WATCHER ISSUE)
> -------------------------------------------------------------------------
>
> Key: JBIDE-13818
> URL: https://issues.jboss.org/browse/JBIDE-13818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Alpha2
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.0.Alpha2
>
>
> This is a watcher issue that helps us tracking the progress of https://bugzilla.redhat.com/show_bug.cgi?id=923369
> In the openshift-java-client integration tests, restarting a stopped application is failing since a few hours (very latest OpenShift origin code):
> https://ci.dev.openshift.redhat.com/jenkins/job/openshift-java-client-dev...
> {code}
> Fehlermeldung
> Could not request https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains/136...: Operation failed.Reason given: " Reference ID: 877bbfd174ddd2b8fec93e4fb560b17a"
> Stacktrace
> com.openshift.client.OpenShiftEndpointException: Could not request https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains/136...: Operation failed.Reason given: "
> Reference ID: 877bbfd174ddd2b8fec93e4fb560b17a"
> at com.openshift.internal.client.RestService.request(RestService.java:106)
> at com.openshift.internal.client.RestService.request(RestService.java:91)
> at com.openshift.internal.client.RestService.request(RestService.java:76)
> at com.openshift.internal.client.AbstractOpenShiftResource$ServiceRequest.execute(AbstractOpenShiftResource.java:124)
> at com.openshift.internal.client.ApplicationResource$StopApplicationRequest.execute(ApplicationResource.java:739)
> at com.openshift.internal.client.ApplicationResource.stop(ApplicationResource.java:245)
> at com.openshift.internal.client.ApplicationResource.stop(ApplicationResource.java:238)
> at com.openshift.internal.client.ApplicationResourceIntegrationTest.shouldRestartStoppedApplication(ApplicationResourceIntegrationTest.java:237)
> 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:616)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> 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:616)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:74)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:194)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:176)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:135)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:616)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: com.openshift.internal.client.httpclient.HttpClientException: {"data":null,"errors":{},"messages":[{"exit_code":-1,"field":null,"severity":"error","text":"\nReference ID: 877bbfd174ddd2b8fec93e4fb560b17a"}],"status":"internal_server_error","supported_api_versions":[1.0,1.1,1.2,1.3,1.4],"type":null,"version":"1.0"}
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:193)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.write(UrlConnectionHttpClient.java:165)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.post(UrlConnectionHttpClient.java:135)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.post(UrlConnectionHttpClient.java:131)
> at com.openshift.internal.client.RestService.request(RestService.java:144)
> at com.openshift.internal.client.RestService.request(RestService.java:98)
> ... 69 more
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains/136...
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1403)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.write(UrlConnectionHttpClient.java:163)
> ... 73 more
> Standard Ausgabe (STDOUT)
> 2013-03-19 11:53:33|INFO |[main]| com.openshift.internal.client.RestService. request | Requesting GET on https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/api
> 2013-03-19 11:53:33|INFO |[main]| com.openshift.internal.client.RestService. request | Requesting GET on https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/user
> 2013-03-19 11:53:33|INFO |[main]| com.openshift.internal.client.RestService. request | Requesting GET on https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains
> 2013-03-19 11:53:33|INFO |[main]| com.openshift.internal.client.RestService. request | Requesting GET on https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains/136...
> 2013-03-19 11:53:33|INFO |[main]| com.openshift.internal.client.RestService. request | Requesting POST on https://ec2-23-22-202-226.compute-1.amazonaws.com/broker/rest/domains/136...
> {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
13 years