| 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.
 
 
      Not sure what you mean here. There are no templates in the reviewed
    patch.
        
 - I don't still follow up the Templates systems, so no
          comments about it yet. I'll have to study it. 
 
      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).
        
 - 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. 
 
      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.
        
 - Why the eContainder doesn't work? 
 
      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.
        
 - 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.
 
 
      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.
        
         - It's alse worthwile, at least to me, having a local
          org.eclipse.ocl.maintenance git repo. 
 
      I don't see any errors.
        
 - 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. 
 
      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.
        
 
          - 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. 
 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.
 
 
      Here too overnight. Melted now and raining again.
        
          
 - It's snowing right now outside o.O. 
 
      
      
      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
 
 |