Several problems were introduced by the PR https://github.com/diverse-project/melange/pull/91 , whose purpose was to have exactly one MelangeResource per adapted resource. Previously, this was not the case when several resources were implied, because a MelangeResource was only created for the originally loaded resource, not for the resources it depended on.
Yet, this broke several things, and Melange tests related to handling multiple resources did not pass anymore, mostly because doAdapt was not called on an indirectly created MelangeResources.
This fix contains the following changes:
When creating a MelangeResource because of a dependency, doAdapt is always called (similarly to the fact that copy was always called for such resources before these changes)
The contentResource containing an adaptation to an MT now has a unique URI based on the adapted resource and on the target MT, which also prevents ResourceSet-related problems and ease debugging
The MelangeResource now has its own ResourceSet, managed by overriding basicSetResourceSet. This fixes problems that could occur when getResourceSet is delegated to the wrappedResource, meaning that a MelangeResource could (often very temporarily) be in a ResourceSet.resources while getResourceSet would return a different ResourceSet
And this time I did not forget to run the tests successfully before offering the PR :)
ebousse
commented
6 years ago
Several problems were introduced by the PR https://github.com/diverse-project/melange/pull/91 , whose purpose was to have exactly one
MelangeResourceper adapted resource. Previously, this was not the case when several resources were implied, because aMelangeResourcewas only created for the originally loaded resource, not for the resources it depended on.Yet, this broke several things, and Melange tests related to handling multiple resources did not pass anymore, mostly because
doAdaptwas not called on an indirectly createdMelangeResources.This fix contains the following changes:
MelangeResourcebecause of a dependency,doAdaptis always called (similarly to the fact thatcopywas always called for such resources before these changes)contentResourcecontaining an adaptation to an MT now has a unique URI based on the adapted resource and on the target MT, which also preventsResourceSet-related problems and ease debuggingMelangeResourcenow has its ownResourceSet, managed by overridingbasicSetResourceSet. This fixes problems that could occur whengetResourceSetis delegated to thewrappedResource, meaning that a MelangeResource could (often very temporarily) be in aResourceSet.resourceswhilegetResourceSetwould return a differentResourceSetAnd this time I did not forget to run the tests successfully before offering the PR :)