Hi, Céline,
Now that I could see the workspace log file, it looks fairly clear that the problem is that the Eclipse Platform is being launched with -Dosgi.os=x86, whereas it should be x86_64. This results in native-library fragments such as SWT not being resolved, because the p2 installation has (correctly) the x86_64 variants.
I should be able to fix this in (I think) the POM. Stay tuned.
On 30 March, 2016 at 09:46:54, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote:
Thanks Christian,
Now the build has finished but still failled..
And I'm not sure that it is due to the Java version, or even your
Commit.
As explained previoulsy even a fake commit doesn't work...
So 2 explainations:
1) Someone has modified the gerrit configuration (we have no
history) and we don't see what it could be.
2) Or it is a depper explaination from dependencies...
I put the Hudson Workspace log detailed in a previous mail in
addition with the Job console details...
Best regards
Céline
Le 30/03/2016 15:31, Christian Damus a
écrit :
Thanks, Céline,
The build was attempting a git clean in the wrong directory; I’ve
fixed that and re-triggered the Gerrit build (thanks for giving me
admin access!).
I’m surprised that Gerrit was using JDK 8 on the master branch.
The long seemed to indicate a 1.7 version. Anyways, a
build is running now and we shall see how it progresses.
cW
On 30 March, 2016 at 05:07:09, Céline
JANSSENS (celine.janssens@xxxxxxxxxxx)
wrote:
Hello Christian,
I have create a new job for Neon branch on Hudson.
By default the JDK is jdk 8... But it is already the case on the
general gerrit job.
So i'm not sure it will change the result.
Let's push the patch again. And see if it trigger the new
gerrit.
HTH
Céline
Le 26/03/2016 12:58, Christian
Damus a écrit :
Hi, Céline,
I’ve pushed my patch to Gerrit as a new change
targeting the Neon branch. I see that a Gerrit build
started on Hudson for this, but as I don’t see any Neon-specific
Gerrit jobs, I expect it will fail just as the other patch did on
the master branch because the Gerrit job is still configured with
the JDK 7.
We would need either
- a new Gerrit build job dedicated to the Neon branch that
builds with JDK 8, or
- just submit this patch to the Neon branch and clone the
Papyrus-RT-Master-All build for the Neon branch (using JDK 8, of
course) and iterate until it builds
Thanks,
Christian
On 25 March, 2016 at 09:50:29, Céline
JANSSENS (celine.janssens@xxxxxxxxxxx)
wrote:
Hi Christian,
I have created a branch called "neon" on Papyrus RT to work on the
Neon version of Papyrus RT to keep the master clean.
In the future, when it is working on this specifi branch, we could
merge it to the Master...
Can you try to push your patch on origin/neon branch ?
Best regards
Céline
Le 25/03/2016 12:20, Christian
W. Damus a écrit :
Hi, Céline,
I like your suggestion of a
branch for the Neon integration that we can merge back to master
later. I am not a committer, so I cannot push a new branch.
But if you create one, then I can re-target my Gerrit patch to it
and you could just submit that patch and create builds for it in
Hudson that use JDK 8. I will be interested to see whether
the rcptt execution works on the eclipse server because that’s the
only part that doesn’t work in my own build.
Anyways, I’ll move the
discussion to the mailing list to loop in Zeligsoft and the rest of
the team.
Thanks,
Christian
Sent from my iPhone
Hello, I'm not sure if I can "remove" -1 from
hudson.
But I can add a +1 to verified and +2 and merge before hudson
finish the job
But before doing that, It would be an additional security to merge
it on another branch than the Master...
Let me know what do you wish me to do ...
Regards
Le 25/03/2016 09:30, LETAVERNIER
Camille a écrit :
I guess Céline can remove the -1 for you, to bypass
the Gerrit reject
I don’t know if there’s any plan for supporting both
the Mars and the Neon branch in parallel (Or at least during the
transition), so I don’t know how much of an issue this would be to
break the Papyrus-RT build for a few days/couple of weeks. It might
be worth discussing this on the Papyrus-RT mailing list when the
patch is ready
Camille
Okay, I can revert what I’ve been doing
in the codegen POM.
But, even so, I won’t be able to convince
Gerrit to give me a +1 vote as long as the codegen build fails and
we aren’t using a JDK 8 for the build (which is required for
execution of tests on Eclipse Neon platform.
Hi Christian,
Regarding the Codegen build, Rémi mentioned (After my previous
answer) that Zeligsoft would take care of this part of the
migration, and that you should focus on the Tooling part of the
build
So you probably don't have to worry about all these parameters
after all
Regards,
Camille
De :
Christian W. Damus [cdamus@xxxxxxxxxxxx]
Envoyé : jeudi 24 mars 2016 20:51
À : Céline JANSSENS
Cc : LETAVERNIER Camille; SCHNEKENBURGER Remi
211865
Objet : Re: Papyrus-RT Build Problems — Blocked
Actually, I just
realized (much later than I should have) that the Gerrit builds for
Papyrus-RT are still configured to run with JavaSE 7.
As the Eclipse Neon
platform requires JavaSE 8, obviously no instance of Eclipse will
be able to launch to run tests. That is the cause of my Error
13 in both Gerrit builds.
So, I cannot proceed
with configuration of a Neon build for Papyrus-RT until we move
Hudson to JavaSE 8.
Hi Christian,
Recently we have refactor the RCPTT plugin, and it seems there are
remaining duplicated folders....
The pom can have some difficulties to find the proper Papyrus
depandencies.
I'll have a look.
Regards
Le 24/03/2016 16:27,
Christian W. Damus a écrit :
Thanks,
Camille,
That does answer
some of my questions:
-
the Papyrus build version dependency is coded as a Hudson build
parameter (papyrus.version = 1.1.3)
-
I may as well migrate the element-types models and the diagram
visual IDs for Papyrus-RT to catch up to both refactorings in Neon
M6
For the first item,
I shall just have to hard-code the papyrus.version dependency in
the POM because I can’t change the Gerrit build configuration (and
it wouldn’t be possible to change it for this one specific Gerrit
change, anyways).
Hopefully that
second item will be able to get the tests passing today.
Perhaps, Céline, you
might have some idea why execution of the RCPTT tests fails for me
with an error about failure to detect the platform version?
You can see my build changes in https://git.eclipse.org/r/#/c/66233/
I’m not a committer on Papyrus-RT, so I only have
limited privileges. I however have read-only access to some of the
build configurations
BUILDTOOLS = x86-gcc-4.6.3
PAPYRUS_UPDATE_SITE = releases
TEST_MODEL = ComputerSystem
BUILDTOOLS = x86-gcc-4.6.3
I don’t have access to the other jobs, but the first
set of parameters might give you some hints as to how actual update
sites are defined. If you need more information, we’ll have to ask
actual committers (e.g. Celine, in cc. I think she’s been working
on the RCPTT part as well)
Ø Is anyone else working on updating the
Papyrus-RT code for the Visual ID changes? I don’t want to
duplicate the effort, but it is necessary in some degree at least
to produce a build.
I don’t think so, but my knowledge is limited. Only
Rémi has been working on the Neon migration so far, and I think he
has pushed everything (I’ve only worked on a patch for the RSA
Model Import, to be integrated once the rest of Papyrus-RT has been
migrated; I think it is completely unrelated since it’s a new
contribution)
Hi Christian,
I will be away from office starting from this evening for 8 days. I
added Camille to the discussion, so he can help you on that
topic.
Regards,
Remi
I’m blocked for now
on attempting to assemble a viable build for Papyrus-RT on Papyrus
Neon M6, for several reasons:
-
there
are numerous test failures in the JUnit tests, I suspect because
test resources need their diagrams to be updated for the new Visual
ID scheme. I’m still looking into this
-
the
Gerrit builds fail, and I’m not sure that the way they are
configured allows me to push a Gerrit change that would pass.
For example, the codegen build is still pulling Papyrus Mars
1.1.3, so some updates for API refactorings don’t compile against
1.1.3. However, I cannot update the releng/codegen/pom.xml to
use Papyrus Neon M6 because then the build ends up with invalid
dependency repository URLs for a neon/1.1.3 update site, which
obviously doesn’t work. It appears that the 1.1.3 is
configured as a parameter in the Hudson build, because I don’t see
it in the POMs, but I cannot verify that because I cannot even see
the Hudson configurations of the builds (never mind edit them,
which I wouldn’t want to do). I could just hard-code the full
repository URLs in the POM instead of letting the build slot the
version number into it, but I don’t want to disrupt the structure
of the build to such degree — let me know if you’d prefer that I
just hard-code it for now
-
the
Tooling gerrit build also fails, with an Error Code 13 in trying to
launch a test workbench. I cannot analyze the problem because
I cannot see the build workspace on Hudson
I have a build that
runs locally, mostly, with a build parameter that lets us choose
whether to use the nightly builds of Papyrus or just the latest
stable build. It has problems that I’d like to see how they
compare on others’ machines:
-
numerous
test failures, as mentioned above, that I’m looking
into
-
the
RCPTT test runner fails to launch properly, with an error message
about failure to detect the "platform version”. There are a
few reports of similar problems on the Internet that have no
resolutions. I’m trying to figure our what the cause of the
problem is by looking through the RCPTT source code. I am
hoping it’s a problem only in my local Ubuntu virtual machine, but
I don’t know yet
Is anyone else
working on updating the Papyrus-RT code for the Visual ID changes?
I don’t want to duplicate the effort, but it is necessary in
some degree at least to produce a build.
But, in the end,
even if I do get a build that runs to completion on my machine, I
don’t know that I can push a Gerrit patch that would actually build
(verified by Hudson); it may be something that needs to be handed
off to a committer to push directly to the repository, by-passing
Gerrit.
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 2016.0.7442 / Base de données virale: 4545/11874 - Date:
24/03/2016
--
|
|
|
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
|
|
Aucun virus trouvé dans ce
message.
Analyse effectuée par AVG - www.avg.fr
Version: 2016.0.7497 / Base de données virale: 4545/11880 - Date:
25/03/2016
--
| |
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 |
|
Aucun virus trouvé dans ce
message.
Analyse effectuée par AVG - www.avg.fr
Version: 2016.0.7497 / Base de données virale: 4545/11880 - Date:
25/03/2016
--
| |
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
_______________________________________________
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
Aucun virus trouvé dans ce
message.
Analyse effectuée par AVG - www.avg.fr
Version: 2016.0.7497 / Base de données virale: 4545/11882 - Date:
25/03/2016
--
| |
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 |
|
|
