Hi Everyone,
The gerrit Job is back to normal.
Regards
Le 25/03/2016 14:50, Céline JANSSENS a
écrit :
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
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
|
|
|