Re: [mdt-ocl.dev] Juno SR2 RC1

[Adolfo Sanchez-Barbudo Herrera <adolfosbh@xxxxxxxxx>]

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