Hi
Comments in line
Regards
Ed
On 14/01/2013 13:34, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,
In principle, it looks OK to me. I have a couple of
thoughts/questions, though.
- 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 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.
- 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).
- 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.
- 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.
- 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.
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.
- It's snowing right now outside o.O.
Here too overnight. Melted now and raining again.
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2638/6031 - Release Date:
01/13/13
|