Hi Christian,
You can find RcpTT logs here[1]
I think the problematic exception is the last one
[2]
Which is strange because the target seems present
[3].
ð
I don’t know what is happening here.
ð
Did you manage to run the tests on your mac?(Add
macosx in the platform)
Some remarks:
-
Product Name papyrusRt (neon) vs PapyrusRT
(master)
-
Even working RcpTT tests have still a bunch of
warnings (see [4])
-
Moving to eclipse target Plaform would maybe help
(see [5], failing due to a wrong localization of
pom.xml?)
Regards,
Benoit
1 :
https://hudson.eclipse.org/papyrus-rt/job/PapyrusRT-Gerrit-for-Neon/ws/source/releng/org.eclipse.papyrusrt.rcptt/target/runner-workspace/.metadata/.log
2 : !ENTRY org.eclipse.osgi 4 0 2016-04-04 10:01:23.033
!MESSAGE Application error
!STACK 1
org.eclipse.core.runtime.CoreException: Invalid
eclipse target platform: No name
/jobs/genie.papyrus-rt/PapyrusRT-Gerrit-for-Neon/workspace/source/releng/org.eclipse.papyrusrt.rcptt/target/aut/papyrusRT
at
org.eclipse.rcptt.internal.launching.ext.Q7TargetPlatformInitializer.getInfo(Q7TargetPlatformInitializer.java:239)
at
org.eclipse.rcptt.internal.launching.ext.Q7TargetPlatformInitializer.initialize(Q7TargetPlatformInitializer.java:100)
at
org.eclipse.rcptt.internal.launching.ext.Q7TargetPlatformManager.createTargetPlatform(Q7TargetPlatformManager.java:129)
at
org.eclipse.rcptt.runner.util.TargetPlatformChecker.initializeTargetPlatform(TargetPlatformChecker.java:112)
at
org.eclipse.rcptt.runner.util.TargetPlatformChecker.initAndCheckTargetPlatform(TargetPlatformChecker.java:70)
at
org.eclipse.rcptt.runner.HeadlessRunner.performCoolThings(HeadlessRunner.java:48)
at
org.eclipse.rcptt.runner.HeadlessRunnerApp.start(HeadlessRunnerApp.java:54)
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:497)
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)
at
org.eclipse.equinox.launcher.Main.main(Main.java:1488)
Contains: Failed to detect platform
version
3:
https://hudson.eclipse.org/papyrus-rt/job/PapyrusRT-Gerrit-for-Neon/ws/source/releng/org.eclipse.papyrusrt.rcptt/target/aut/papyrusRT/
4:
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Gerrit-master/ws/source/releng/org.eclipse.papyrusrt.rcptt/target/runner-workspace/.metadata/.log
5: https://git.eclipse.org/r/#/c/65272/15
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de
Christian Damus
Envoyé : lundi 4 avril 2016 16:06
À : papyrus-rt developer discussions
<papyrus-rt-dev@xxxxxxxxxxx>; Céline JANSSENS
<celine.janssens@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Why is the Java8 JRE in
Hudson a 32-bit build?
Now,
after configuring the Neon gerrit job to use the 64-bit Java8, we
get past the problem of not being able to load the SWT native
library. With another configuration change to enable Xvnc for
the test execution so that the X11/Gtk environment is available to
SWT, I can report that my Gerrit patch [1] for porting Papyrus-RT
to Papyrus Neon M6 now only has the problem that I originally got
stuck on in my local test builds: RCPTT cannot detect the
target platform:
!MESSAGE Detected potential problems in target platform No Name
Installation /jobs/genie.papyrus-rt/PapyrusRT-Gerrit-for-Neon/workspace/source/releng/org.eclipse.papyrusrt.rcptt/target/aut/papyrusRT Default Configuration
Directory /jobs/genie.papyrus-rt/PapyrusRT-Gerrit-for-Neon/workspace/source/releng/org.eclipse.papyrusrt.rcptt/target/aut/papyrusRT/plugins
Env: null/null/null/null
JRE: null
Args: null/null
Implicit: null
Handle: 1459778481221.target
I
understand that you are doing some work on the RCPTT execution.
Do you recognize this? I haven’t even been able to find
the source code in the RCPTT Git repository for the component that
attempts to infer the target platform, to guess at how to give it
what it needs. I can find the code that bombs the execution
on finding that the target platform wasn’t resolved, but not the
code that is responsible for that resolution step.
On
4 April, 2016 at 03:35:48, Céline JANSSENS (celine.janssens@xxxxxxxxxxx)
wrote:
Hi
Everyone,
The JDK 64bits has been added to the installed JDKs.
I hope it will help for the Neon installation.
Regards
Céline
Le
31/03/2016 11:27, Céline JANSSENS a écrit :
Hello
everyone,
I have created the ticket :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=490763
To ask a JRE 8 on a 64bit HIPP instance.
Regards
Céline
Le
31/03/2016 10:09, Céline JANSSENS a écrit :
I
do not have such access.
As far as I know Remi doesn't have it as well.
The quickest would be to open a ticket.
Regards
Céline
Le
30/03/2016 20:10, Christian Damus a écrit :
Surely
somebody on this mailing list has the requisite admin access to the
HIPP. I agree that we can have no need for the 32-bit
VM.
On
30 March, 2016 at 12:14:37, LETAVERNIER Camille (camille.letavernier@xxxxxx)
wrote:
FWIW, on the Papyrus Hudson instance, I had to manually configure
the JDK-8 variable to the following:
jdk1.8.0-latest = /shared/common/jdk1.8.0_x64-latest
I had to do this because, at the time, it wasn't pre-configured by
webmasters. I don't know how much this has changed now. If someone
has admin rights on the Papyrus-RT HIPP, then he can configure
something similar. Otherwise, you need to open a ticket on Bugzilla
so that Webmasters can take care of that for you
HTH,
Camille
hi,
Peter,
I don’t know what
the XULRunner is for. But in any case my work-around doesn’t work
because 32-bit SWT fails to resolve libpthread. So I’m
stuck until I can get a 64-bit Java 8.
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
|
Céline JANSSENS
Software
Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
|
Céline JANSSENS
Software
Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
|
Céline JANSSENS
Software
Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
To change your delivery options, retrieve your password, or unsubscribe from this list, visit