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
|
|
|
