Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Java8 support 
Hi Folks,
I've gotten the below implemented, but I've noticed that on some occasions the automated test projects are failing to launch, and I don't understand why. Specifically, for the C-HEAD-remoteservice.generic.feature, the build job gets through the compile phase and then it has the below as output. 

Although it says:

ERROR: The application could not start. Details can be found in the log.
ERROR: The application could not start. Details can be found in the log.
I can't find the log that it's referring to...there's nothing in the test xml output, and the workspace .log file doesn't have any useful information.
My suspicion is that some how the java8 code fouls up the start of the test runner...because the java version being used for the test run is < java8. That's my suspicion. 

Does anyone have more info about how to diagnose this test run fail?

Thanks,

Scott

[workspace] $ java -Dbuckminster.output.root=/opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/buckminster.output -Dbuckminster.temp.root=/opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/buckminster.temp -Xmx768m -Xms768m -XX:PermSize=512M -XX:MaxPermSize=512M -Decf.p2.repository=http://download.ecf-project.org/repo/ -Dsite.include.top=true -Dsite.signing=false -Dsite.pack200=true -Dstaging.area=/home/data/httpd/download-staging.priv/rt/ecf -Dsigning.type=eclipse.remote -Declipse.committer.name=mkuppe -Declipse.committer.keyfile=/usr/share/tomcat5/.ssh/id_rsa -Dqualifier.replacement.*=generator:buildTimestamp -Dgenerator.buildTimestamp.format='v'yyyyMMdd-HHmm -DtargetPlatformPath=/opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/targetPlatformPath -DprojectsPath=/opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/projects -Dosgi.console.enable.builtin=true -jar /opt/hudson/tools/hudson.plugins.buckminster.BuckminsterInstallation/Buckminster_4.3/buckminster/plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar -application org.eclipse.buckminster.cmdline.headless -data /opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace --loglevel debug -S /opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/commands.txt
bglaunch '--launch' 'org.eclipse.ecf.tests.remoteservice.generic/org.eclipse.ecf.tests.remoteservice.generic.host.launch' '--ignoremissing'
Doing full workspace refresh
Cancel jobs that are known to run indefinitely...
CANCELED JOB: (org.eclipse.core.internal.utils.StringPoolJob) Compacting resource model(13)
Waiting for jobs to end
junit '--launch' 'org.eclipse.ecf.tests.remoteservice.generic/org.eclipse.ecf.tests.remoteservice.generic.launch' '-o' '/opt/hudson/jobs/C-HEAD-remoteservice.generic.feature/workspace/junit_result.xml' '--flatXML'
ERROR: The application could not start. Details can be found in the log.
ERROR: The application could not start. Details can be found in the log.
WARN:  Process /opt/hudson/tools/Java1.4.2_update_18_x86-64/jre/bin/java (Apr 11, 2014 11:34:21 PM) terminated with exit status 13.
Doing full workspace refresh
Cancel jobs that are known to run indefinitely...
Waiting for jobs to end
java.lang.IllegalArgumentException: Export has failed because no test session is available. (Maybe the argument -maxTimeAwaitJunitReport will help)
	at org.eclipse.buckminster.junit.internal.ResultSerializer.<init>(ResultSerializer.java:74)
	at org.eclipse.buckminster.junit.JUnitCommand.exportTestRunSession(JUnitCommand.java:132)
	at org.eclipse.buckminster.junit.JUnitCommand.internalRun(JUnitCommand.java:102)
	at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:86)
	at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:200)
	at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:343)
	at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:284)
	at org.eclipse.buckminster.cmdline.Headless.start(Headless.java:358)
	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)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Build step 'Use builders from another project' marked build as failure
Recording test results
Archiving artifacts
Sending e-mails to: slewis@xxxxxxxxxxxxx
Sending e-mails to: slewis@xxxxxxxxxxxxx
Finished: FAILURE



On 4/11/2014 8:02 AM, Scott Lewis wrote:

Hi Folks,

In the short term, I've decided to do the following:
1) Build the asyncproxy 1.0.0 and 2.0.0 (j8) bundles locally on my Eclipse 4.4+java8-enabled system. 
2) Place the resulting p2 repo on download.eclipse.org
3) Modify the builds of several of the projects (the remoteservice projects) to use the p2 repo (2) as the source for the binaries of these two bundles.
I've done this, and the resulting SDK build is here (which does include 1.0 and 2.0 versions of asyncproxy) [1].
In the short term (Luna M7/ECF 3.8.1) this will serve to include the j8 support for remote services in ECF 3.8.1...and it doesn't require rewiring the entire build in order to build one method of one class using Buckminster+Eclipse+Java8 (which...excepting some example code...the only j8 code that exists in ECF right now).
This is not a long term solution...i.e. I do want to eventually move everything on the build up to using java8...so that we can add more things (e.g. examples, etc) that use CompletableFuture more easily, but given the lack of resources available these days, it will have to serve. 

Thanks...and Markus and Wim...if we can get together let's please do so.

Scott
[1] http://build.ecf-project.org/repo/C-HEAD-sdk.feature/lastSuccessful/archive/site.p2/ 

On 4/10/2014 10:07 AM, Scott Lewis wrote:

On 4/10/2014 9:51 AM, Markus Alexander Kuppe wrote:

On 04/10/2014 06:33 PM, Scott Lewis wrote:
Thanks for the diagnosis Wim. I suppose we have to point at a recent integration build for 4.4...as even 4.4 didn't have java8 support until 
quite recently.

Wim...for coordination...would you rather do/try this, or should I?


Hi,
please note that the Jenkins Buckminster plugin doesn't support 4.4 yet. 
We will have to install a 4.4. Buckminster with the director manually
for the moment. Then, add a (manually installed) buckminster
installation in the global jenkins config and update the build templates 
to use this new installation.
Unfortunately, I don't know how to do these step...at least without further explanation/details (e.g. 'director manually' and 'manually installed'). And my guess is that this may also require shell access...and I'm still waiting on support@xxxxxxxxxx for that.
Can we schedule something in coming week?...among me, Markus, and Wim...to get the necessary steps hammered out/communicated/detailed...and then I...or someone else if available/desired...will complete? 

Thanks,

Scott



HTH
Markus

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top