Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 360629 - [Eugenia] Minor inconsistencies in the workflow
Summary: [Eugenia] Minor inconsistencies in the workflow
Status: CLOSED FIXED
Alias: None
Product: Epsilon
Classification: Modeling
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Antonio Garcia-Dominguez CLA
QA Contact:
URL:
Whiteboard: interim
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-12 04:52 EDT by Antonio Garcia-Dominguez CLA
Modified: 2012-11-08 16:39 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Garcia-Dominguez CLA 2011-10-12 04:52:29 EDT
Hi all,

While I was writing the Spanish book chapter on EuGENia, I noticed a few minor inconsistencies in the EuGENia workflow:

1. We have a menu entry called "Synchronize EMF gen model", and another called
   "Synchronize GMF GenModel". How about using "GenModel model" and
   "GMFGen model", instead?

2. The only way to invoke the "Synchronize EMF gen model" action is from the
   drop-down menu in Eclipse. The all-in-one "Generate GMF editor" doesn't call
   it, and for that reason, the Ant task doesn't either. Should we call it
   as well?

3. The ECore metamodel is exposed as "ECore" in some polishing transformations,
   and as "Ecore" in others. Should we use "ECore" everywhere?

4. The ECore metamodel is stored again in GenerateToolGraphMapDelegate.
   Shouldn't we set store=false in that case?

5. I already exposed with read=true and store=false the GmfGraph model in the
   FixGMFGen step. While we're at it, perhaps we should expose the other GMF
   models in the same way?

Except for step 3, I think most of these changes are safe. What are your thoughts on this?
Comment 1 Dimitris Kolovos CLA 2011-10-17 03:48:35 EDT
#1 sounds OK

#2: yes - that's an omission in the current version

#3 could break existing code. We should probably use both (ECore could be an alias so that we preserve backward compatibility)

#4 rings a bell as something that was deliberate at the time - although I must admit I don't quite remember what the issue was when store was false

#5 sounds good to me
Comment 2 Antonio Garcia-Dominguez CLA 2011-10-17 16:10:17 EDT
I'll work on #1-#3 and #5 then, and leave #4 as is.
Comment 3 Antonio Garcia-Dominguez CLA 2012-03-05 14:38:43 EST
I have implemented #1-#3 and #5. I'll wait until we get this into an interim release to update the Eugenia article in the website.
Comment 4 Dimitris Kolovos CLA 2012-07-03 06:44:12 EDT
This has been fixed in the latest interim version.

Antonio: it should now be OK to update the Eugenia article accordingly.
Comment 5 Dimitris Kolovos CLA 2012-11-08 16:39:48 EST
Fixed in 1.0