Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Juno SR2 RC1

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.

Cheers,
Adolfo.

Inline images 1


On 14 January 2013 11:06, Adolfo Sanchez-Barbudo Herrera <asbh500@xxxxxxxxxx> wrote:
Hi Ed,

A good chance to try to oil the rusty machine ;). I'll review all the changes and try to understand the new stuff.

Cheers,
Adolfo.


On 14 January 2013 10:51, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

Thanks for the reminder.

No plans.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=394152 has a patch awaiting a review by you. You can probably satisfy yourself quite quickly that any possible impact is limited to examples plugins. The only 'difficult'  bit is the version numbers.

We made such a mess of the early Kepler version numbers that these will need careful review.

        Regards

            Ed


On 14/01/2013 10:36, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,

Could you send to me your plan of introducing any change to the maintenance branch during today/following days ?.

I've discovered a branch which may be you want to merge into the maintenance branch:

origin/bug/394152

N.B: SR2 RC1+1 is today.

Cheers,
Adolfo.


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




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



Back to the top