[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Juno SR2 RC1
|
Hi
On 16/01/2013 12:21, Adolfo Sanchez-Barbudo Herrera wrote:
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 which view "it" is. You can certainly do this in the GIT
History View.
- 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.
They're a pain, but what UML specify.
- 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 ;).
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.
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.
Please don't. It works, but I'm not comfortable with it. It's due for a
major clean up.
Regards
Ed
