|Re: [mdt-ocl.dev] Juno SR2 RC1|
Hi Ed, Pending email to reply. Comments in-lined below.
- While having checkd out maintenance/R4_0 branch, If I "synchronize with workspaspace" against the origin/bug/394152, the syncronize view doesn't show changes for the CompositionProperty class (There is a screenshot below). EGit funny ? Update: After your rebase, now it properly appears the changes in the ocl.examples.pivot plugin.I haven't used the Synchronize view for ? a year. With GIT the History View is much much more powerful and what is actually debugged.
I find it quite useful, you even may compare two branches/tags without having checked out any of those you are comparing. For tasks like detecting which changes have occurred between 2 releases and verifying that its version number was properly increased, is essential.
- I don't still follow up the Templates systems, so no comments about it yet. I'll have to study it.Not sure what you mean here. There are no templates in the reviewed patch.
A TemplateableElement element is used. I dont control the MOF/UML/Pivot Templates system. I'll need to have a look to it.
- What is the "single containment type" ? Which is the complex one? May an eobject be contained throught different features by different objects ?. This puzzles me.For instance in Ecore, you might think an EReference could only be contained by an EClass (the simple case), but actually it can also be contained by an EAnnotation.eContent (the complex case).
There is the following comment, which mentions the "single containter type"eValue = eObject.eContainer(); // FIXME this only works for single container type
Thus my confussion. Anyway I've not used EReferences apart from its normal usage on EClasses, so no idea about the other way. I guess that the eContainer() operation doesn't consider this complex case, does it ?
update: Answered below.
- Why the eContainder doesn't work?eContainer() works for the actual containment. CompositionProperty is concerned with a specific one such as EReference.eContainingClass for which the assumption that EReference.eContainer() is the same fails when the containment is EAnnotation.eContents.
I think that I have an answer to my previous question. We are at MM level, looking for the container for an EReference, which may be an EClass (simple case) or an EAnnotation (complex case). At M1 level, every EObject will properly obtain its eContainer() regardless the containment EReference is defined via the simple or the complex case.
Or at least, I hope so ;P.
- Although my main development IDE is currently Kepler M4. I find necessary to use a Juno installation to do the maintenance reviews (to avoid complation errors, launch test cases, etc). In Open we configured target platforms to develop against. I'm not sure if you are fond of them.I tried a target platform again a few months ago and it didn't work at all. Maybe I was trying to work forwards: an M3 platform on 'M0', rather than backwards, Juno on Kepler.- It's alse worthwile, at least to me, having a local org.eclipse.ocl.maintenance git repo.Yes you certainly need multiple repos per major platform. Sometimes multiple repos per development branch are helpful to avoid having to commit one WIP in order to switch to another.
As long as they are not pushed, I don't see any problem of doing partial commits. And Im not sure neither which problem we may have with a push with partial commits, providing we know that its WPI ;).
- I've got 3 failures in xtext tests (just the maintenance/R4_0 branch - without the bug changes). Let me know if you experiment the same, or my Juno IDE needs some tune up.I don't see any errors.- It's being occurring as too many times as I desired that I have to kill JVM to close Eclipse, due to hanging jobs, which doesn't complete and ignore you when you try to cancel them. This time a lot of uncancellable jobs which say "Re-indexing repository org.eclipse.ocl/qvtd/qvto". This was not so frequent with Helios and SVN.You mean CVS. Killing re-indexing is counter-productive. Some of the pending jobs are short but clog up the list. It takes time to learn which ones matter. I often find that it helps to disable Auto-build before any major GIT activity to avoid GIT restarting builds at every project change. Once GIT is happy, re-enable auto-builds.
Not ideal, certainly.
I'm pretty sure there are also significant problems with one or more Modeling Project builders; certainly Acceleo seems to rebuild very slowly very frequently. Closing the examples.build and examples.codegen plugins can help. I found the ergonmics of Acceleo editing/building so disappointing for OCL codegen that I've migrated all the codegen templates to direct Java M2T. (I tried Xtend briefly, just in case, but its significant deviations from Java (as well as OCL) made me uncomfortable.) This eliminates the OCL run-time dependency on Acceleo breaking a nasty installation loop. Hopefully this will be on master for M5.
mmm.... interesting. I'll have a look to that Java M2T. Cheers, Adolfo.
_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
Back to the top