|Re: [mdt-ocl.dev] Juno SR2 RC1|
Hi On 16/01/2013 12:21, Adolfo Sanchez-Barbudo Herrera wrote:
Not sure which view "it" is. You can certainly do this in the GIT History View.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.
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.A TemplateableElement element is used. I dont control the MOF/UML/Pivot Templates system. I'll need to have a look to it.
They're a pain, but what UML specify.
You can push them as well. It's just that once committed, you lose some of the nice features of the Index in the Staging View. But I'm gradually learning to do the appropriate Reset so that you can get back to an uncommitted state.- 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 ;).
Please don't. It works, but I'm not comfortable with it. It's due for a major clean up.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 Acceleobreaking a nasty installation loop. Hopefully this will be on master for M5.mmm.... interesting. I'll have a look to that Java M2T.
Back to the top