[JBoss JIRA] (JBIDE-21725) Use RedDeer 1.x nightly in master builds
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21725?page=com.atlassian.jira.plugi... ]
Martin Malina edited comment on JBIDE-21725 at 3/8/16 10:23 AM:
----------------------------------------------------------------
[~mickael_istria], ok, so I created a PR to add the RedDeer repo to master parent pom:
https://github.com/jbosstools/jbosstools-build/pull/213
Can you or [~nickboldt] push this?
Once that's done, we can remove the property from integration tests root pom.
was (Author: mmalina):
[~mickael_istria], ok, so I created a PR to add the RedDeer repo to master parent pom:
https://github.com/jbosstools/jbosstools-build/pull/213
> Use RedDeer 1.x nightly in master builds
> ----------------------------------------
>
> Key: JBIDE-21725
> URL: https://issues.jboss.org/browse/JBIDE-21725
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: target-platform
> Affects Versions: 4.3.1.Beta2
> Reporter: Martin Malina
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> Martin said:
> {quote}Nick Boldt, ok, I will discuss this with others and then get back to you - I'm not sure if now is the right time to pull a nightly or we should wait.
> I think the intention was to have this in the TP so that we know exactly what is used with which version of JBT - just look in the corresponding TP. That's also how it works for server depending on base - it's the same version. But pointing to RedDeer master repo is different.
> After discussion with Rastislav Wagner, here's our proposal: What if we stick with RedDeer master repo in our pom for integration tests master? For maintenance branch (4.3.x), it's good that we have a stable version of RedDeer in the TP and we can use that. But for JBT master, we can rely on the RedDeer master repo directly and later when we start testing JBT 4.4.0.Alpha1, we may put some version of RedDeer to the TP and switch to that.
> What do you think? Makes sense?
> So if you agree, this would mean that for now we won't use RedDeer in TP 4.60.0 - so either you can just leave it there until we replace it with a new version, or you could even remove it.{quote}
> Nick said:
> {quote}Makes sense. When stable, add to TP; until stable, just use nightly.
> Re: updating 4.60.0.Alpha1, unless there's a compelling reason to remove it from the TP, I'm good to leave 1.0.1 in there [1].
> [1] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.6...
> Let me know if you need assistance setting up your pom to depend on Red Deer 1.x nightly URL.{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21725) Use RedDeer 1.x nightly in master builds
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21725?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21725:
---------------------------------------
[~mickael_istria], ok, so I created a PR to add the RedDeer repo to master parent pom:
https://github.com/jbosstools/jbosstools-build/pull/213
> Use RedDeer 1.x nightly in master builds
> ----------------------------------------
>
> Key: JBIDE-21725
> URL: https://issues.jboss.org/browse/JBIDE-21725
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: target-platform
> Affects Versions: 4.3.1.Beta2
> Reporter: Martin Malina
> Assignee: Nick Boldt
> Fix For: 4.4.0.Alpha1
>
>
> Martin said:
> {quote}Nick Boldt, ok, I will discuss this with others and then get back to you - I'm not sure if now is the right time to pull a nightly or we should wait.
> I think the intention was to have this in the TP so that we know exactly what is used with which version of JBT - just look in the corresponding TP. That's also how it works for server depending on base - it's the same version. But pointing to RedDeer master repo is different.
> After discussion with Rastislav Wagner, here's our proposal: What if we stick with RedDeer master repo in our pom for integration tests master? For maintenance branch (4.3.x), it's good that we have a stable version of RedDeer in the TP and we can use that. But for JBT master, we can rely on the RedDeer master repo directly and later when we start testing JBT 4.4.0.Alpha1, we may put some version of RedDeer to the TP and switch to that.
> What do you think? Makes sense?
> So if you agree, this would mean that for now we won't use RedDeer in TP 4.60.0 - so either you can just leave it there until we replace it with a new version, or you could even remove it.{quote}
> Nick said:
> {quote}Makes sense. When stable, add to TP; until stable, just use nightly.
> Re: updating 4.60.0.Alpha1, unless there's a compelling reason to remove it from the TP, I'm good to leave 1.0.1 in there [1].
> [1] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.6...
> Let me know if you need assistance setting up your pom to depend on Red Deer 1.x nightly URL.{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21824) Content assist for image names in "Deploy Docker Image" wizard
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21824?page=com.atlassian.jira.plugi... ]
Fred Bricon resolved JBIDE-21824.
---------------------------------
Resolution: Done
Fix for JBIDE-21802 backported in master
> Content assist for image names in "Deploy Docker Image" wizard
> ---------------------------------------------------------------
>
> Key: JBIDE-21824
> URL: https://issues.jboss.org/browse/JBIDE-21824
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.0.Alpha1
>
>
> The {{Image Name}} field could be enhanced with content assist based on the list of image names+tags retrieved from the selected Docker connection.
> If the user inputs a name that does not match the list, a warning on the page would inform him/her that a remote call to the registry would be performed upon page completion, ie, when clicking on the {{Next}} button.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21170) Problems with CDK Adapter resulting from missing PATH in Eclipse on Mac
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21170?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-21170.
---------------------------------
This works for me in latest JBDS 9.x snapshot.
> Problems with CDK Adapter resulting from missing PATH in Eclipse on Mac
> -----------------------------------------------------------------------
>
> Key: JBIDE-21170
> URL: https://issues.jboss.org/browse/JBIDE-21170
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.3.1.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.1.CR1
>
>
> The problem is that CDK tooling relies on PATH to find vagrant. And the "vagrant up" command in turn depends on PATH to find e.g. VBoxManage.
> On Mac, when you start your Eclipse / JBDS as an app by double-clicking an icon on your Desktop or in Finder, the Eclipse instance will have no PATH env variable.
> One workaround is to start your Eclipse from command line by going inside the package:
> {code}
> cd Eclipse.app/Contents/MacOS
> ./eclipse
> {code}
> But this is definitely not the recommended way to start Eclipse - I'm not sure if eclipse.ini is located properly in this case. But at least PATH is correct then.
> There is actually one more workaround. To add your PATH to the Environment tab in Launch config. That works for me.
> So that might be a potential solution to this problem - have a predefined PATH for each OS in case there is none defined in the Eclipse process.
> After I set up a CDK server adapter and fixed the wrong path to vagrant in the launch config, I then started the server adapter and got this:
> Server CDK Server Adapter at localhost failed to start.
> Console:
> {code}
> The provider 'virtualbox' that was requested to back the machine
> 'default' is reporting that it isn't usable on this system. The
> reason is shown below:
> Vagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.
> Vagrant uses the `VBoxManage` binary that ships with VirtualBox, and requires
> this to be available on the PATH. If VirtualBox is installed, please find the
> `VBoxManage` binary and add it to the PATH environmental variable.
> {code}
> Along with this, there was an Unhandled event loop exception in the error view:
> {code}
> org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException)
> at org.eclipse.swt.SWT.error(SWT.java:4491)
> at org.eclipse.swt.SWT.error(SWT.java:4406)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4024)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3700)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:520)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.updateEarlyAccess(GettingStartedHtmlPage.java:359)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage.access$14(GettingStartedHtmlPage.java:342)
> at org.jboss.tools.central.editors.GettingStartedHtmlPage$6$1.run(GettingStartedHtmlPage.java:327)
> at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:162)
> at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:154)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
> at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
> ... 23 more
> {code}
> In the command line, VBoxManage is accessible and it is located in /usr/local/bin/ and on my PATH.
> Max suggested I could try to start Eclipse from command line instead of double-clicking in Finder (which is the normal way to do it on Mac) and that helped.
> So for some reason when you start Eclipse using Eclipse.app from Finder, the PATH is incorrect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21829) Error while opening Eclipse with OpenShift Server Editor opened
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21829?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-21829:
----------------------------------
Description:
I get the following error when my runtime Eclipse starts with the Server Editor opened on an OpenShift Server Adapter:
{code}
!ENTRY org.eclipse.core.jobs 4 2 2016-03-08 15:54:58.597
!MESSAGE An internal error occurred during: "Setting connection, deploy project...".
!STACK 0
com.openshift.restclient.authorization.ResourceForbiddenException: User "test-admin" cannot list all services in the cluster
at com.openshift.internal.restclient.DefaultClient.createOpenShiftException(DefaultClient.java:477)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:152)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:133)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:128)
at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:434)
at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:377)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:267)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:256)
at org.jboss.tools.openshift.internal.ui.server.OpenShiftServerEditorSection$13.run(OpenShiftServerEditorSection.java:486)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{code}
This error also happens when the editor is closed at start-up and opened later on.
was:
I get the following error when my runtime Eclipse starts with the Server Editor opened on an OpenShift Server Adapter:
{code}
!ENTRY org.eclipse.core.jobs 4 2 2016-03-08 15:54:58.597
!MESSAGE An internal error occurred during: "Setting connection, deploy project...".
!STACK 0
com.openshift.restclient.authorization.ResourceForbiddenException: User "test-admin" cannot list all services in the cluster
at com.openshift.internal.restclient.DefaultClient.createOpenShiftException(DefaultClient.java:477)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:152)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:133)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:128)
at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:434)
at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:377)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:267)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:256)
at org.jboss.tools.openshift.internal.ui.server.OpenShiftServerEditorSection$13.run(OpenShiftServerEditorSection.java:486)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{code}
On the other hand, this error does not happen when the editor is closed at start-up and opened later on...
> Error while opening Eclipse with OpenShift Server Editor opened
> ---------------------------------------------------------------
>
> Key: JBIDE-21829
> URL: https://issues.jboss.org/browse/JBIDE-21829
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Xavier Coulon
>
> I get the following error when my runtime Eclipse starts with the Server Editor opened on an OpenShift Server Adapter:
> {code}
> !ENTRY org.eclipse.core.jobs 4 2 2016-03-08 15:54:58.597
> !MESSAGE An internal error occurred during: "Setting connection, deploy project...".
> !STACK 0
> com.openshift.restclient.authorization.ResourceForbiddenException: User "test-admin" cannot list all services in the cluster
> at com.openshift.internal.restclient.DefaultClient.createOpenShiftException(DefaultClient.java:477)
> at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:152)
> at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:133)
> at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:128)
> at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:434)
> at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:377)
> at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:267)
> at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:256)
> at org.jboss.tools.openshift.internal.ui.server.OpenShiftServerEditorSection$13.run(OpenShiftServerEditorSection.java:486)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> This error also happens when the editor is closed at start-up and opened later on.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21829) Error while opening Eclipse with OpenShift Server Editor opened
by Xavier Coulon (JIRA)
Xavier Coulon created JBIDE-21829:
-------------------------------------
Summary: Error while opening Eclipse with OpenShift Server Editor opened
Key: JBIDE-21829
URL: https://issues.jboss.org/browse/JBIDE-21829
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta2
Reporter: Xavier Coulon
I get the following error when my runtime Eclipse starts with the Server Editor opened on an OpenShift Server Adapter:
{code}
!ENTRY org.eclipse.core.jobs 4 2 2016-03-08 15:54:58.597
!MESSAGE An internal error occurred during: "Setting connection, deploy project...".
!STACK 0
com.openshift.restclient.authorization.ResourceForbiddenException: User "test-admin" cannot list all services in the cluster
at com.openshift.internal.restclient.DefaultClient.createOpenShiftException(DefaultClient.java:477)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:152)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:133)
at com.openshift.internal.restclient.DefaultClient.list(DefaultClient.java:128)
at org.jboss.tools.openshift.core.connection.Connection.retryList(Connection.java:434)
at org.jboss.tools.openshift.core.connection.Connection.getResources(Connection.java:377)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:267)
at org.jboss.tools.openshift.core.server.OpenShiftServerUtils.getService(OpenShiftServerUtils.java:256)
at org.jboss.tools.openshift.internal.ui.server.OpenShiftServerEditorSection$13.run(OpenShiftServerEditorSection.java:486)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{code}
On the other hand, this error does not happen when the editor is closed at start-up and opened later on...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21710) [CDK] replace calls to adbinfo plugin with service-manager plugin
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21710?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21710:
---------------------------------------
[~maxandersen] I tried it now - when adbinfo is not installed, it works fine as expected. But if I remove service-manager as well, cdk start will fail.
The console will say:
{code}
vagrant-service-manager plugin is not installed, run `vagrant plugin install vagrant-service-manager` to install the plugin.
{code}
And there will be an error pop up saying:
{code}
'Starting <server_name> ' has encountered a problem.
Server <server_name> failed to start.
{code}
So while the error window does not explain what exactly is wrong, you will see the console telling you exactly what you need to do. So I think this is sufficient. Feel free to open a JIRA if you feel otherwise.
> [CDK] replace calls to adbinfo plugin with service-manager plugin
> -----------------------------------------------------------------
>
> Key: JBIDE-21710
> URL: https://issues.jboss.org/browse/JBIDE-21710
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: cdk, server
> Reporter: Navid Shaikh
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.3.1.CR1
>
>
> vagrant-service-manager plugin [1] is a successor for vagrant-adbinfo plugin [2].
> All further development towards displaying and configuring provider [docker, openshift, kubernetes, etc] information from ADB / CDK, will happen in vagrant-service-manager plugin.
> Equivalent functionality from vagrant-adbinfo plugin is now ported to vagrant-service-manager plugin.
> To display docker connection information from vagrant box,
> using adbinfo
> ```
> $ vagrant adbinfo
> ```
> using service-manager
> ```
> $vagrant service-manager env docker
> ```
> Kindly update the tooling which are using adbinfo plugin with service-manager command.
> Note: adbinfo plugin has a dependency on `scp` / `pscp` utility for copying certs. service-manager plugin does not need `scp` / `pscp` utility to copy the certs.
> [1] https://github.com/projectatomic/vagrant-service-manager
> [2] https://github.com/projectatomic/vagrant-adbinfo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21788) builds for master and jbosstools-4.3.x are failing due to typo in parent pom
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21788?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-21788:
---------------------------------------
That's because it's the other JIRA number that's used. But I get it - the typo was from the other issue. So I can live with that :)
> builds for master and jbosstools-4.3.x are failing due to typo in parent pom
> ----------------------------------------------------------------------------
>
> Key: JBIDE-21788
> URL: https://issues.jboss.org/browse/JBIDE-21788
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.CR1, 4.4.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Nick Boldt
> Priority: Critical
> Labels: build, jenkins
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> Both jenkins builds for [jbosstools-4.3.x|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbo...] and [master|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-op...] are currently failing for openshift. I cant reproduce it locally, the error looks like some configuration error
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec (deploy-snapshot-build) on project openshift.site: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec (deploy-snapshot-build) on project openshift.site: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 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:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour.
> at org.codehaus.mojo.exec.ExecMojo.handleArguments(ExecMojo.java:490)
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:250)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21788) builds for master and jbosstools-4.3.x are failing due to typo in parent pom
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21788?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21788:
------------------------------------
You just have to look for 'em.
https://github.com/jbosstools/jbosstools-build/commit/db2c41bc468a841ab5f...
https://github.com/jbosstools/jbosstools-build-sites/commit/6828b9e4ffa0a...
> builds for master and jbosstools-4.3.x are failing due to typo in parent pom
> ----------------------------------------------------------------------------
>
> Key: JBIDE-21788
> URL: https://issues.jboss.org/browse/JBIDE-21788
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.CR1, 4.4.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Nick Boldt
> Priority: Critical
> Labels: build, jenkins
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> Both jenkins builds for [jbosstools-4.3.x|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbo...] and [master|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-op...] are currently failing for openshift. I cant reproduce it locally, the error looks like some configuration error
> {code}
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec (deploy-snapshot-build) on project openshift.site: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:exec (deploy-snapshot-build) on project openshift.site: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 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:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Misconfigured argument (8), value is null. Set the argument to an empty value if this is the required behaviour.
> at org.codehaus.mojo.exec.ExecMojo.handleArguments(ExecMojo.java:490)
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:250)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month