Closed GoogleCodeExporter closed 9 years ago
This issue was closed by revision 85fb55ac4ee1.
Original comment by de.abg.r...@gmail.com
on 4 Dec 2012 at 7:22
I've waited for this fix :)
Im developing my ecore metamodel in iterations, e.g. if i need new EClasses or
EAttributes, etc. i add them, but the Spray Project couldnt resolve these newly
added EClasses.
So i always created a new Spray Project, because i didnt know how to update the
Spray Project itself.
Does your fix consider this kind of development of the ecore metamodel ?
Thank you :)
Original comment by Nosezeic...@gmail.com
on 5 Dec 2012 at 9:37
It is common use case to change the domain model while building the diagram
model (as you often recognize missing elements in the domain model when
defining the mapping to the diagram).
The calculation of EPackages and EClasses is cached, as this is called very
often inside the calculation of the scoping for the DSL. So it is only
recalculated when there are workspace changes (changes to projects, import
of new projects). I exclude changes to the Spray project itself as this
would lead to endless regeneration. The fix considers the case when the
change status of all projects in the workspace has not calculated yet as
well as the case when there workspace changes that do not effect resources
(e.g. the change is the creation of new project). I did not test this for
Spray installed via update site, just for Spray started in a runtime
workspace.
Also note that have to regenerate the Java sources via genmodel when you
changed the ecore model.
Joerg
Original comment by de.abg.r...@gmail.com
on 6 Dec 2012 at 8:13
Original issue reported on code.google.com by
de.abg.r...@gmail.com
on 1 Dec 2012 at 8:19