Hi,
Thanks for the detailed feedback. Some additional comments:
Ø
-
Properly support all platforms (Including 32 bits, which have been disabled – or never enabled)
Ø
Ø
As I said previously, we can only build the runtime, for now at least, in Linux.
This is actually related to providing RCPs/Products for all available platforms, independently from which platform is
used to actually do the build. Even if the runtime is not supported on Windows, it’s still a good idea to provide RCPs for these platforms, so that people can at least work on the models. Currently, only Windows 64, Linux/GTK 64 and MacOSX are targeted by
the build. I’ve added 32 bits support for Linux and Windows (I think Eclipse dropped support for Mac 32 bits a couple of years ago)
Ø
I think you've identified most of them for codegen, but I noticed that in your change you left "simrel-repo.url" in the codegen pom. This is later used by the xtumlrt EMF plugins. Since you define the 'eclipse-simrel'
repo in the top-level pom, wouldn't it make sense to move that variable up as well?
Indeed, I forgot to remove the variable from codegen. I didn’t notice that the xtumlrt plug-ins did define their own local
build configuration. This build configuration seems quite similar for each of the metamodel plugins, so they should probably have a common parent pom regrouping these. In general, I like to avoid putting specific build configuration in individual plug-ins.
When you have many plug-ins, it becomes difficult to identify which plug-ins need to be updated when changing the build configuration. In most cases, moving the build configuration to a top-level pom is easier, as most builders just do nothing when applied
on incompatible artifacts (e.g. invoking the xtend builder on a standard java plug-in should be harmless).
Ø
On the codegen side we only do junit tests (no UI required) and the postbuild.sh script does an Eclipse install with the required codegen, runtime and profile features and then runs the code generator in stand-alone
mode (no UI, not even headless Eclipse).
If you’re using Tycho/Surefire, the top-level pom configures the test runtime with all required UI dependencies. If you’re
not using surefire, then this item only applies to the Profile/Core/Tooling tests. Since Profile tests do not require UI, my goal was to change this configuration to make the UI dependency optional (Only for the test plug-ins which actually require it)
Ø
Also, given my limited understanding of maven, and in particular of its override mechanism, in the xtumlrt EMF plugins we declare some dependencies and repositories as part of the tycho-eclipserun-plugin
configuration. Perhaps this could also be moved up
Tycho-eclipserun is quite generic. I think it would be a little bit risky to move the configuration up. While this makes
sense for all *.model plug-ins, this would probably not be relevant for hypothetical other usages of eclipserun. So moving this configuration up in a new intermediate pom (in xtumlrt/metamodel/) would definitely make sense; but moving it up to the top-level
pom seems risky and not really future-proof.
Ø
We also declare a bunch of plugins such as tycho-compiler-plugin, maven-antrun-plugin, and xtend-maven-plugin.
Are these needed by tooling?
-
Tycho-compiler: yes
-
Xtend-maven: maybe later, if e.g. xtext-based editors are introduced in diagrams
-
Maven-antrun: no
Tycho-compiler and Xtend-maven have already been added to the top pom’s <pluginManagement>, so that at least the version
is common to all plugins. For antrun, I think it is very specific to codegen (Using ant with maven should be a last resort option), so it probably doesn’t need to be moved up
Ø
Good question. Do you mean the Maven build (would Gerrit allow you to publish?)
I mean the archive.sh script that is executed at the end of postbuild.sh. This script is executed on Gerrit builds as
well, whereas I think it only makes sense for actual master/maintenance builds
Ø
I think that was probably accidental? I think Céline created it.
Maybe we should remove the Java nature.
I’ve removed it in the last patch set
Ø
I saw the comment in the pom, but I'm not sure how we could solve it. The conflict would occur when buildAll = true? What are the consequences? The build may fail if there is some mismatch between what's provided
by the ${papyrus-rt-profile-repo.url} from codegen and what's being built?
It could result in false-negative or false-positive builds. For example, it might find an older version of the codegen
plugins in the “PapyrusRT-All” update site, which no longer exist, and use them to resolve some invalid dependencies (Rather than properly failing)
Ø
I don't know if perhaps there should be a "Tooling-only" build as well? (so you don't have to build codegen+rts when doing tooling-only changes).
I think so (Especially since it’s how it works currently). We could use a specific profile for building subsets of Papyrus-RT.
That would be easier than adding a new intermediate pom between the root and the Profile/Core/Tooling modules, and probably cleaner too. I’ve never tried adding modules in a profile, but it seems to be supported by Maven.
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Ernesto Posse
Envoyé : mardi 12 avril 2016 19:12
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Papyrus-RT p2 Repositories
Hi Camille. Thanks for looking into this. I have some comments, answers and questions in-lined below.
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)
As I said previously, we can only build the runtime, for now at least, in Linux.
If we want to build for all platforms, would it be possible to disable the runtime build on platforms other than Linux? I don't know how to go about it. Is there something like an optional module in maven?
-
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
I think you've identified most of them for codegen, but I noticed that in your change you left "simrel-repo.url" in the codegen pom. This is later used by the xtumlrt EMF plugins. Since you define the 'eclipse-simrel' repo in the top-level
pom, wouldn't it make sense to move that variable up as well?
-
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)
On the codegen side we only do junit tests (no UI required) and the postbuild.sh script does an Eclipse install with the required codegen, runtime and profile features and then runs the code generator in stand-alone mode (no UI, not even
headless Eclipse).
-
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
Also, given my limited understanding of maven, and in particular of its override mechanism, in the xtumlrt EMF plugins we declare some dependencies and repositories as part of the tycho-eclipserun-plugin configuration.
Perhaps this could also be moved up. I'm not sure how exactly to go about it. Do we add the tycho-eclipserun-plugin to pluginManagement at the top? Do we leave them where they are, but remove the <repositories> and <dependencies> tags from their <configuration>?
We also declare a bunch of plugins such as tycho-compiler-plugin, maven-antrun-plugin, and xtend-maven-plugin. Are these needed by tooling? You probably won't need the maven-antrun-plugin which we use for building the runtime, but I've
seen the tycho-compiler-plugin invoked for the core, profile and tooling plugins. And Xtend? It doesn't seem to be used in core/profile/tooling now, but maybe later?
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)
I'm not sure about this either. I think Charles said in another thread that the import is not part of version 1.0, so perhaps we can leave it like that for now?
-
Is it expected that the Gerrit build actually publishes artifacts to the download server? (Although in a specific folder)
Good question. Do you mean the Maven build (would Gerrit allow you to publish?) I don't know about this one. On the codegen side, it's the postbuild.sh script that publishes to the update site, but only after the "full-cycle test" (i.e.
installs Eclipse with the codegen, rts and profile, runs the stand-alone generator, compiles and runs the generated code). If we do the publishing in Maven, would it be possible to do that kind of "full-cycle test" there? How? Perhaps with the maven-antrun-plugin?
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 think that was probably accidental? I think Céline created it. Maybe we should remove the Java nature.
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)
I saw the comment in the pom, but I'm not sure how we could solve it. The conflict would occur when buildAll = true? What are the consequences? The build may fail if there is some mismatch between what's provided by the ${papyrus-rt-profile-repo.url}
from codegen and what's being built?
I don't know if perhaps there should be a "Tooling-only" build as well? (so you don't have to build codegen+rts when doing tooling-only changes).
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)
Postbuild.sh does the following:
1. copies the generated repo from ${LOCAL_REPO_DIR}/releng/codegen/site/target/repository to the builds/repository in the downloads area
2. executes the runtest.sh which:
2.1. installs eclipse (mars right now) with the uml2, codegen, rts, umlrt-profile features
2.2. runs the standalone code-generator (umlrtgen.sh in o.e.p.codegen.standalone) on a sample model
2.3. builds the generated code (on linux with gcc-4.6.3)
3. executes archive.sh which copies the generated repository to the update site, and also zip it and copies it to the archives folder
I noticed that failure. I went through our dependencies and we had one plugin (o.e.p.codegen.papyrus) requesting 0.7.1. I'll push a fix to master shortly.
It also complains that the bundle o.e.core.runtime 3.12.0 cannot be found. That's probably because the script is installing Mars rather than Neon. I'll push a patch.
The last errors, I've no idea.
Objet : [PROVENANCE INTERNET] Re: [papyrus-rt-dev]
Papyrus-RT p2 Repositories
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
Envoyé : vendredi 8 avril 2016 10:28
Objet : [PROVENANCE INTERNET] Re: [papyrus-rt-dev]
Papyrus-RT p2 Repositories
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
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.
Papyrus-RT-Master-All was designed to actually be all-in-one, but since I couldn’t get
the codegen part to compile on Windows, this has never been completed [1]
This was almost one year ago, so I guess this contribution can be abandoned now. XT-UML-RT
arrived a little bit later, so at the time, it was “All but codegen”
[1] 49755: Bug 469722: [Releng] Configure Maven build for Papyrus-RT [I7bdedf5e]
https://git.eclipse.org/r/#/c/49755/
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Peter Cigéhn
Envoyé : jeudi 7 avril 2016 15:04
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Papyrus-RT p2 Repositories
Welcome to the confusion! :)
I have been asking myself these questions also several times. I can try to explain my understanding of your questions. Hopefully someone
with better insight can correct if I am wrong.
On 7 April 2016 at 14:54, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Team,
I am trying to track down reliable p2 repositories for assembly of Papyrus-RT in a new Oomph setup model, and I have some questions:
-
the “Papyrus-RT-Master-All” build on Hudson produces a repository containing only the core and tooling plug-ins, not xtumlrt nor codegen. Why? That doesn’t sound like “all” of Papyrus-RT to me
The "why" part I really don't know. I guess no one has had the time to get it "all" of Papyrus-RT together in one place.
-
it appears that the only p2 repositories for the codegen and xtumlrt plug-ins are the following. Is that correct?
This repo is built by a CM tigger, i.e. it should be built triggered by pushes to master.
The same as the other one, but instead of being trigger by a push to master, it is trigger nightly (independent of if something has
been pushed or not).
As I understood it, this was planned to get in place post-0.7.2. But since we have not built anything post-0.7.2, I
guess that could explain why it is empty.
Nope, the nightly builds (triggered by pushing to master, and not trigger each night as for the code-generator/run-time) of core/profile/tooling
parts
is only available on the p2 repo on Hudson.
_______________________________________________
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
_______________________________________________
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
|
