search

eclipse-qvto / org.eclipse.qvto

Eclipse Public License 2.0
0 stars 0 forks source link

Refactor ResourceSet creation #1027

Open eclipse-qvt-oml-bot opened 15 hours ago

eclipse-qvt-oml-bot commented 15 hours ago

| --- | --- | | Bugzilla Link | 537040 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 15, 2018 05:36 EDT | | Modified | Aug 01, 2018 04:58 EDT | | See also | 533155 | | Reporter | Ed Willink |

Description

Bug 533155 identifies a failure due to a null ResourceSet and prompted a refactoring. See comments 6,7,8 of Bug 533155.

eclipse-qvt-oml-bot commented 15 hours ago

By Christopher Gerking on Jul 31, 2018 11:56

(In reply to Ed Willink from comment #0)

Bug 533155 identifies a failure due to a null ResourceSet and prompted a refactoring. See comments 6,7,8 of Bug 533155.

My changes for bug 537041 reduce the number of different ResourceSets in use. In particular, we get rid of specially configured ResourceSets with custom URI-resource maps. In the absence of such special configurations, a central place to create/initialize ResourceSets now seems no longer strictly required. Thus I'm inclined to resolve this as won't fix or invalid.

The situation might be different when we find out that we should configure different ResourceSets with specific URI mappings as demanded by bug 533564. If so, creating all ResourceSets from a central place appears reasonable again.

eclipse-qvt-oml-bot commented 15 hours ago

By Ed Willink on Aug 01, 2018 04:58

In principle this seems good, but I'm not really familiar enough with the code to review. Only Sergey can give you a +1. Two ResourceSets seems to be the right way to go; one tooling, one user.

However from a selective browse:

The cloneResourceSet methods etc were comment-free and their functionality was not obvious from their name. The new (and old) methods could usefully have a function comment.

--

You have changed the signature of methods such as cloneResourceSet. Since QVTo keeps access very tight with internal packages and limited friends, this is no doubt ok wrt strict API regulation. QVTo is a leaf project with very limited client projects, very few clients use the APIs, but I suspect those that do are forced to drive a bulldozer through the access warnings, in part because QVTo has many warnings about exported non-API types in public signatures, see Bug 533919. It therefore seems prudent to proceed in two stages:

a) refactor the APIs so that the compiler diagnoses all obsolete usages\ b) restore the old APIs wherever possible as wrappers to the new

--

CompilerUtils.addMappingsToResourceSet uses IResource which will fail for standalone usage. I see that this is just a refactored failure, but it may explain some of your standalone ResourceSet anomalies.