Hi,
Ø
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.
Papyrus-RT-Gerrit-master is definitely building with JDK 7:
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Christian Damus
Envoyé : mercredi 30 mars 2016 15:49
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>; Céline JANSSENS <celine.janssens@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Papyrus-RT Build Problems — Blocked
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 :
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.
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 :
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.
-
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
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 :
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.
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
|
|
|
