Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] 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 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.


_______________________________________________ mailing list

Back to the top