Hi
I was only looking at Example 4, so I only fixed the two Example 4
tests. there were 7 other failures.
Regards
Ed
On 22/12/2015 12:43, Adolfo
Sanchez-Barbudo Herrera wrote:
Hi,
Did you run all test cases ? or just the NewExample4 one ?
Regards,
Adolfo.
On 22/12/2015 11:55, Ed Willink
wrote:
HI
Now available on OCL ewillink/480567.
Alternatively you can just skip the "Add incremental API"
commit. Probably easier since it adds
CS2ASJavaCompilerParameters.isIncremental.
Regards
Ed
On 22/12/2015 11:41, Adolfo
Sanchez-Barbudo Herrera wrote:
Hi Ed,
I believe you have forgotten to push some OCL-bits. Something
related to the incremental execution, which is required by
ewillink/mtc4
Regards,
Adolfo.
On 22/12/2015 11:18, Ed Willink
wrote:
Hi
If I've got something good that has significant conflicts
with master
Check out somethingGood.
Reset mixed to master.
Review GIT changes
If the changes are substantial, partition into themes, and
select all changes for one theme, commit, test. Repeat till
done.
If whitespace/reordering changes have crept in, it can help
to adjust somethingGood to avoid the confusing aesthetic
chnages until the important functional changes are resolved.
Reducing the number of auto-generated files that participate
in GIT commits also simplies what needs checking.
It's a pain, but it seems the only way of catching the
subtle XML file chnages.
-----
ewillink/mtc4 removes some irregular code in QVTp2QVTg whose
sole purpose now seems to be in preventing oclContainer()
working. With the extra commit, Example 4 can use
oclContainer() or oclContainer.
-----
Beware of reviewing related multi-test results. If
xxxExample4_YYY follows xxxExample4_ZZZ a failure in
xxxExample4_YYY may be due to dirty registrations left
behind by xxxExample4_ZZZ. Assess failures individually,
then resolve the inter-test registration corruptions.
On 22/12/2015 10:59, Adolfo
Sanchez-Barbudo Herrera wrote:
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|