| Re: [papyrus-rt-dev] Eclipse Installer errors due to Papyrus |
+1 for a Saturday night I-build. But it will really only matter if Papyrus does the same.
Also, I’m in theory supportive of continuing the practice of continuing with separate Codegen and Tooling builds, even adding more for Common and probably also xtUML-RT. This promotes componentization with well-defined stable interfaces, testability, etc. Exactly what we are (very slowly because it’s such a big task) working towards in Papyrus with the Neon refactorings and whatever comes next.cW_______________________________________________On 26 May, 2016 at 14:25:18, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
_______________________________________________Christian and Ernesto,
Yes, I understand the point now. You would prefer a real version of the nightly build or an integration build. The nightly build would be the literal definition of the build, e.g. a version produced once per day, hopefully in a dead time zone for the committers. That makes sense in that case, rather than relying on the very last binaries produces by the git. I am ok with such a solution. One week would be perhaps a bit long for some of the evolution we currently have, but as Christian does, I personally have all the sources for core and tooling (and common now) opened in the workspace, as Papyrus-RT is a quite small sized project.
So the action point there would be to define an integration build&deploy job on Papyrus (and Papyrus-RT) for that purpose, running every Saturday evening?
I get caught for my dependency issue on a patch growing more and more as soon as I was getting more and more feature into my bug, while some work was being added on top of master. I should have react earlier and split the contribution into smaller pieces. I don’t know how complex it will be to split it into several contributions.
For the build running on a single job, that was also one of the ideas behind Céline reconfiguring the architecture and the pom structure, but we are facing here the complexity of understanding/merging 2 different approaches/conventions into the same build, while rushing for the release 1.0.
The discussion with Camille earlier was about the complexity of dependency management. Either you have a monolithic component (or build), and then you have no issue of dealing with the dependencies, as everything is build at once, but you can have a long time of build and feedback (In the Papyrus case, rebuilding the whole tool because you made a change to a leaf plugin can be a hard time for the committers and Eclipse infrastructure, with the current issues we have in gerrit jobs being not able to run the tests). Or you start working with split components/builds, and you end up with complexity for dependency management and also build configuration like our current case.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : jeudi 26 mai 2016 20:03
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Eclipse Installer errors due to Papyrus
Hi, Rémi, Ernesto,
Many Eclipse projects publish weekly integration builds (“I-builds”). These are expected to be a bit more tested and stable than nightlies, and they only build once a week and can easily be aimed at a timeslot that nobody in our (more-or-less) two time zones will run into. This would be the ideal situation, I think, for me because (a) I rarely check out source projects from Papyrus into my RT workspace and when I do, they are current; and (b) I check out all of the RT Core and Tooling source projects in my workspace so it it would hardly matter that they are up to a week behind in my target platform.
Rémi, for the dependency problem of your patch, that is exactly the main reason to have everything built by one job (at least in Gerrit, if not nightly/integration builds). We had a contribution in that direction which has gone stale and probably needs considerable overhaul now. Should we try to pursue that again? Alternatively, your patch might be staged in three pieces: one that can be built tested and merged on the base (profile/library) bits first, another the tooling bits, and the last the codegen bits. It’s almost like dealing with changes that span multiple git repositories. 😕
Cheers,
Christian
On 26 May, 2016 at 13:31:50, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
Hi Ernesto,
I don’t think having this deploy job would change anything to the issue. You are consuming some data which is being changed, and you fall down on the transition time. Results would be the same if you put it on a download area or on the Hudson server.
I think the RC2 build should not impact the nightly builds, so there should not be any consequences here. The only difference may be the higher number of commits on these busy days, so the Papyrus nightly has more transition times.
To tackle these issues of being dependent of nightly bits, one solution would be to depend only on milestones or on released Papyrus(-RT) binaries, as these ones are moving not so often. But that would mean that you would not benefit from the latest fixes or improvements of Papyrus, sometimes required for some evolution on Papyrus-RT.
Maybe the other people in charge of Papyrus or Papyrus-RT would have a different insight here.
While we are speaking of dependencies, I currently cannot (or prefer not) to merge the stuff around default language framework, because the gerrit-coden is failing in my patch [1]. This is due to the fact that the cogen build is targeting the nightly builds of Papyrus-RT master all, where my new feature/plugin is still not pushed, as it is being added with the contribution being built on common area (the famous rts uml model plugin…). There could be in this case some more detailed rules on the gerrit trigger to launch or not the gerrit jobs, or the gerrit jobs should be cascading or “smarter”, but I am afraid we are facing a technology issue there. We discussed a bit with Camille about that issue this evening, but we do not see any good solution.
Regards,
Rémi
[1] https://git.eclipse.org/r/#/c/73509/
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Ernesto Posse
Envoyé : jeudi 26 mai 2016 18:48
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] Eclipse Installer errors due to Papyrus
I, and at least one other person, have been getting errors while attempting to install the developer environment and there are errors resolving papyrus bundles.
I understand this can happen while the Hudson build is replacing the repos, is this the case?
I saw a message on the mdt.papyrus.dev mailing list that they were building RC2 yesterday. Could this be the cause?
This reminded me of a message I posted on May 11 ("Tooling Gerrit builds and p2 repo"), asking if we could have more stable p2 repos for the tooling side (an actual nightly) so that we don't have this problem. There was only one response from Peter, but no one from Tooling has responded. Could we create a Hudson job to publish the Core/Profile/Tooling to a nightly repo? (Hopefully Papyrus would do that too)
Thanks
--
Ernesto Posse
Zeligsoft
_______________________________________________
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