Re: [papyrus-rt-dev] Virtual doughnuts — build post-mortem

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Thanks for the doughnuts!

A (possibly dumb) question for future reference: is the lesson here that, in the general case, whenever we remove a bundle, we need to first make sure that no other components depend on that bundle, and removing the downstream dependencies on that bundle before merging the change that removes the bundle?

--

Ernesto

On Wed, Jan 11, 2017 at 7:59 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Thanks, Rémi,

I’ll try adding a kick of the UMLElementTypes class into the ElementTypesRule to see if that helps.  It was because these tests already use that rule to try to evade this problem that we’ve seen so often, that I was perplexed.

cW

On Jan 11, 2017, 03:39 -0500, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>, wrote:

Hi Christian,

Thanks for the donuts, even virtual ones ;) 

I got a quick overview on your issue this morning, and it seems related to the element types coming from UMLElementTypes from uml service types. As soon as the tests are failing, they seem to be in the neighborhood... 

I don't really like that class, and those generated by GMFtooling for each diagram. The registry is dynamic now, with reload/unload of configurations, and those classes are statically defined. As soon as an element type configuration is loaded, the static reference may be lost. So I would try to ensure that the registry is fully loaded with the UMLElementTypes nicely defined. 

HTH

Cheers...

Rémi

2017-01-10 23:54 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:

Hi, Team,

To approximate an age-old tradition of software development offices, please enjoy a tray of virtual doughnuts with my apologies for today’s spate of broken builds.

                       Image by joefoodie licensed under Creative Commons CC BY 2.0.

As it happens, I got myself stuck in a tough spot in our build system with inter-component dependencies.  A contribution in the Core component that removed an obsolete plug-in bundle org.eclipse.papyrusrt.umlrt.core.sync passed Hudson Gerrit build validation and was merged, but this broke the Tooling component build which still thought it needed that bundle.  There was already a gerrit patch waiting in the wings that would update the Tooling component to remove the dependency on this bundle, but now it could not build because the Gerrit builds are based on the full Product build, which could never successfully build because the Tooling build was broken.  So, there was no way to get an updated Product build that provided what the Tooling Gerrit build needs while the main Tooling build was broken, but of course the usual Gerrit process could not push fixes to the Tooling component without the Gerrit build.  This was all further complicated by the fact that the main Core build is based on the last successful Product build because the Core Tests need the Tooling component (some of the tests run in diagram editors).

So, long story short, I should have anticipated this problem and only deleted the obsolete sync plug-in as a final step, after all other changes to all components were merged, and I had to by-pass Gerrit to push my updates including temporarily reinstating the sync plug-in, to get the builds working again.

There are still test failures in the main Core build that I don’t understand:  they look like kind of failures usually caused by the Element Types Registry not being populated, but that can’t be the cause here because the tests employ the ElementTypesRule.  Moreover, the Core Gerrit build job doesn’t manifest these test failures.  I shall continue to investigate this, tomorrow.  Any ideas about the nature of this problem will be most welcome.  🤕

Cheers,

Christian 

_______________________________________________
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

--

Remi Schnekenburger

Senior Software Architect / General Manager

EclipseSource Paris

Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19

EclipseSource France SAS
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Remi Schnekenburger

_______________________________________________
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

--

Ernesto Posse

Zeligsoft