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