Hi, Ernesto,
Yes, the nuance that I didn’t account for in my split and ordering of commits was that, although my commit in the Core component that removed the sync bundle built fine and passed all the tests, this was only because the Core component’s target platform includes the previous Core component build. So, the target platform supplied the bundle that I had deleted.
I think that this is a mistake in the Core component’s target platform selection. The build is configured to select the “releng” TP for the Core build, which is intended primarily for the Product build to get all the Papyrus-RT bits that it needs to assemble into the repo and RCP. This TP is selected because the Core tests run in the diagrams, and so need the Tooling Component.
Therefore, I have further recommendations to make 😉:
- first, that we change the “core” TP to include the latest tooling build, in order to satisfy the test requirement, and then remove the “target.kind=releng” property from the Core build config in Hudson so that it will use its proper TP
- next, that we work on removing the dependency on the diagrams (and any other Tooling dependency) in the Core tests. This involves a lot of re-writing of existing test cases
- then, we can remove the Tooling component from the Core TP that we added in step 1
On Jan 11, 2017, 12:04 -0500, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
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
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
_______________________________________________
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