Yes Camille,
I just modified it ;)
Le 30/03/2016 15:53, LETAVERNIER
Camille a écrit :
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
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
|
|
--
| |
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
|
|
|
