| Re: [papyrus-rt-dev] Papyrus-RT p2 Repositories |
|
Hi, The global build has been refactored and is now pretty much working. There are however
a few more steps (and questions) to complete the work. For the steps: -
Properly support all platforms (Including 32 bits, which have been disabled – or never enabled) -
Identify all variables used in POMs and merge them whenever relevant. I’m not sure about all of them so there’s probably much more that
can be cleaned up -
Improve the test configuration, especially to distinguish between UI Tests and non-UI tests. Currently, all tests are executed in a UI
Environment, even if they don’t require it (Resulting in more expensive and less accurate testing) -
Move more Maven plugins to the top pom (When they are used in several components, e.g. Core, Tests, Tooling, Codegen...), and override
them as necessary for specific usages (Rather than copying everything). Using properties/variables might help as well Regarding the questions and remarks: -
What should be the current version number? Currently the plugins are 0.7.2 (Except the RSA-RT Import, which
targeted the Neon release before it actually existed, and is versioned 0.8.0. But this plug-in is not merged yet) -
Is it expected that the Gerrit build actually publishes artifacts to the download server? (Although in a specific
folder)
o
It seems that the Gerrit configuration is very close to the standard one, including everything related to publishing
artifacts. This means that we need to be very careful when duplicating a job for random testing -
The releng project is defined as a Java project (So all folders appear as packages, which is very confusing).
Is that expected, or accidental? I also had to fix the following to improve consistency and solve conflicts: -
For Tooling, we used a variable named “tycho-version”, and for Codegen, “tycho.version”. I removed the dash
one, to consistently use “tycho.version” everywhere -
The codegen update site POM ID was the same one as the Tooling one. When built together, this introduced a conflict.
o
The codegen site is now called “org.eclipse.papyrusrt.codegen.p2”, instead of “org.eclipse.papyrusrt.p2”. This
is just a build artifact, so this shouldn’t have any consequence -
A new profile has been added to Codegen’s pom.xml: “BuildCodegenOnly”, enabled by default. When the profile
is enabled, an additional update site is added to the list of repositories (To let codegen find the Papyrus-RT Tooling). This update site is not required when we build everything at the same time, because Papyrus-RT Tooling is part of the same build.
o
buildAll = false: when building Codegen only (DEFAULT)
o
buildAll = true: when building everything (Needs to be defined explicitly, e.g. as a build parameter) Currently the build is failing on the Codegen postbuild.sh script. I’m not sure what it does, but it seems to explicitly
request PapyrusRT 0.7.1 (Even for the –Neon builds). My job is configured with PapyrusRT 0.7.2, and it fails on an install step. So I’m not sure if Codegen is ready for Neon yet, or if I missed something. The errors happens after the Maven build (Which is
successful). I’m not sure how this part works, so there’s not much I can do (Except reverting this specific part to PapyrusRT 0.7.1, but this wouldn’t make much sense) (Almost complete) Gerrit patch:
https://git.eclipse.org/r/#/c/70225/ Failing Codegen deployment:
https://hudson.eclipse.org/papyrus-rt/job/Papyrus-Gerrit-Master-All/7/console Bugzilla : 469722: [Releng] Configure Maven build for Papyrus-RT https://bugs.eclipse.org/bugs/show_bug.cgi?id=469722 Regards, De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille FYI, a new ‘maven’ branch with an associated Gerrit job ‘Papyrus-Gerrit-Master-All’ has been created.
It is based on the current ‘master’ branch I’ll work from here and try to see what’s required to get a unified build, without affecting the current modularity Camille De :
papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille Hi, I’ll have a look into this again, since I can now use Gerrit for my tests (Back in 2015, Gerrit was broken and I could
only use Windows, so I was unable to test anything) I think at least the following elements need to be shared: -
Repositories for dependencies (Eclipse, Papyrus), so that Codegen and Tooling use the exact same versions -
Common Maven plugins and versions, because we can’t mix different versions of the same Maven plugins in the
same build (That’s not an issue today as we use separate builds) Camille De :
papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Ernesto Posse Sorry for the late response. I think some of these questions have already been clarified. As for the reasons, first, we ended up having separate p2 repos for codegen/runtime on one hand and core/profile/tooling on the other because we have been working in two largely independent teams on these two sides and each side made their
own decisions. As for the codegen side, I don't know exactly why we ended up with that particular structure of build/ and update/ folders. I don't know who created those top-level folders (but I did create the builds/gerrit and builds/repo folders). I would expect that once we have a unified build we can publish to updates/nightly. Wouldn't that make sense? As for being unable to build on Windows, that is expected because our side included the (C++) runtime, which, at least for now, only supports Linux, as that was chosen from the beginning as the first target platform for the runtime. There
is some Windows support, but I don't know how complete that is. I think the priority for 1.0 is still Linux. On several occasions I've mentioned that we could unify the maven builds, but I won't touch the top-level pom, as I don't know what are the consequences for core/profile/tooling, and perhaps someone with more maven experience than me could
take a look at our pom(s) to see what we could refactor and move up to share, while retaining the capability to build separately. On Thu, Apr 7, 2016 at 9:11 AM LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
|