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