Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] Post-M4 commits

Hi Ed,

Comments in-line below.

Regards,
Adolfo.

On 22/12/2015 08:26, Ed Willink wrote:
Hi

The major problem is the plugin.xml registrations. These are useful to publish installed models and StandaloneProjectMap observes them in standalone contexts. However such declarations in JUnit tests are counterproductive leading to fights between any installed versions and development versions. They also clutter a nested Eclipse with unwanted models. Particularly bad when nsURIs / qualifiedClassNames are not unique. Therefore test plugins should not declare models. Instead I added InstallMap to add/remove the declarations in each test. The genmodel needs at least "PluginKey" to be blank to avoid corrupting plugin.xml on regeneration.
Ok.

Since oclContainer is a navigation, it was much easier to model it as a Property in the new scheduler. OCLstdlib now provides both oclContainer() and oclContainer. oclContainer works for Example 4. I'll look at supporting oclContainer().

See ewillink/mtc4.

Your rebase involves nearly 400 files, almost as many as I had to resolve for the new scheduler integration.

It is very hard to review these changes accurately.
Perhaps it's hard, but rebasing the same conflicting files changed in many different commits is a nightmare, as of current EGit tooling. I had to squash them together to do a sensible/more consistent rebase.

I suggest pursuing a similar policy as I adopted. Flatten all the changes and re modularize. Divide and conquer. One commit for Example 5. One for Example 4. One for ... in an order where you can test each for success. Bigger easy commits first. With smaller commits, checking for bad conflict resolution as in the *.genmodel, plugin.xml is much more tractable. You will also avoid a confusing history that makes and then retracts changes to e.g. plugin.xml.
If you are suggesting to split a big commit into many, I'm unsure how to do that. Perhaps, doing a soft reset after rebasing the big commit ?. I'll have a look at google.


You will probably find it helpful to avoid reordering in OCL2QVTiTestCases.java or whitespace cleanup in MtcBroker.java until an update is complete. You will need to do many GIT Complete Trees and so want to minimize obfuscation.

    Regards

        Ed

On 22/12/2015 06:57, Ed Willink wrote:
Hi

On 21/12/2015 16:13, Adolfo Sanchez-Barbudo Herrera wrote:
- All new scheduler test cases fail. Perhaps a trivial fix, but I've not looked into it to discover what is cause the test to fail. Example 2 has changed, but that was not a problem for the flat scheduler. Example 4, had a minor rework in the CS2AS description (apart from fixing the Node::depth feature name).
I'll look at Example 4.

    Regards

        Ed


_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev


Back to the top