|
Ed,
Comments below.
On 26.09.2017 10:13, Ed Willink wrote:
Hi
Today, I think the EMF GenModel changes should just be an
opportunity. The new EAnnotation support should allow UML's
<genAnnotations
source="http://www.eclipse.org/emf/2002/GenModel/importer/org.eclipse.uml2.uml.ecore.importer">
<details key="DUPLICATE_FEATURES" value="PROCESS"/>
<details key="DUPLICATE_FEATURE_INHERITANCE"
value="PROCESS"/>
...
to be visible and editable in the EMF editors.
Yes, although we digress, EMF 2.14 has added annotation validators
well as a bunch of other cool generic features as described in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=418619#c2 so you can
easily see which extended metadata annotations are possible:
You can also easily set any GenModel properties as annotations
directly in the Ecore model, and yes, that's a real checkbox cell
editor in the properties view:
However again today, with 2 bug fixes on the new support not
yet available in an N-build, it is not possible to rebuild the
OCLUML.uml models; the genmodel takes a long time as usual but
many of the generated files terminate after the imports, which
is often an indication of bad templates.
There is an N-build:
I can't comment on UML2's support, but I did fix
https://bugs.eclipse.org/bugs/show_bug.cgi?id=521871 so that UML2's
templates can actually be compiled.
I suspect that the EMF template evolution to support
@deprecated/@since tags is breaking for UML2. There is new
GenModelUtil API used by the templates and since this is build
time API there is no need to provide runtime-level
conditionalization.
Yes, the use of GenModelUtil in the templates required UML2 to
change it's templates, though I offered to use it in fully qualified
form rather than importing it...
Again, I digress, but documentation annotations are now processed to
handle @since and @deprecated in a special way, e.g., for the
features I added to the GenModel I used @since 2.14:
It now generates the @since tag on each generated artifact derived
from the Ecore artifact so documented, e.g., not just the expect
thing on the primary artifact where model documentation is normally
generated:
/**
* Returns the value of the
'<em><b>Documentation</b></em>' attribute.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* <!-- begin-model-doc -->
* @since 2.14
* <!-- end-model-doc -->
* @return the value of the '<em>Documentation</em>'
attribute.
* @see #setDocumentation(String)
* @see
org.eclipse.emf.codegen.ecore.genmodel.GenModelPackage#getGenTypedElement_Documentation()
* @model unsettable="true" suppressedIsSetVisibility="true"
suppressedUnsetVisibility="true"
* @generated
*/
String getDocumentation();
But also every other generated artifact such as this
/**
* Sets the value of the '{@link
org.eclipse.emf.codegen.ecore.genmodel.GenTypedElement#getDocumentation
<em>Documentation</em>}' attribute.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @param value the new value of the
'<em>Documentation</em>' attribute.
* @see #getDocumentation()
* @since 2.14
* @generated
*/
void setDocumentation(String value)
andthis
/**
* This adds a property descriptor for the Documentation feature.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @since 2.14
* @generated
*/
protected void addDocumentationPropertyDescriptor(Object object)
Anything that uses EMF 2.14 code generation must support EMF
2.14. For OCL and QVTd, I just had to add an extra import of
GenModelUtil and merge my variant Class.javajet with the evolved
EMF Class.javajet. For QVTd where code generation can be a
user-compile time activity, I considered adding
conditionalisation on all the new API so that QVTd would be
Oxygen installable, I'm still considering but since QVTd
graduates this year I might decide that it graduates on current
code unless UML has died....
An important thing to note is that EMF still installs in Kepler (and
compiles against Kepler), so I see no need to do anything obtuse to
make any EMF dependencies not exploit EMF 2.14.
Regards
Ed Willink
On 26/09/2017 08:21, Ed Merks wrote:
Sebastien
I think you are misinterpreting "require UML2's extended
GenModel to take action" as synonymous with "the changes are
bad."
Any change (good or bad) to the GenModel.ecore affects (at
least potentially) UML's extended GenModel implementation.
http://git.eclipse.org/c/emf/org.eclipse.emf.git/log/plugins/org.eclipse.emf.codegen.ecore/model/GenModel.ecore
Also any change to templates (good or bad) affects (at least
potentially) UML's specialized templates:
http://git.eclipse.org/c/emf/org.eclipse.emf.git/log/plugins/org.eclipse.emf.codegen.ecore/templates/model/Class.javajet
We can all be thankful (and I
certainly am!) that Itemis consistently sponsors my
contributions and that Dennis Hübner of TypeFox does the
Releng work on my behalf.
Note that lack of signing support for Buckminster builds will
become a significant problem for someone, or perhaps everyone,
when the foundation disables that service.
Regards,
Ed
On 26.09.2017 08:03, GERARD Sebastien wrote:
Hi Ed,
Can you tell me what are the changes that have been made
and will be bad for photon w.r.t. EMF generator part?
Thanks.
Best.
Seb.
Envoyé
depuis mon smartphone Samsung Galaxy.
-------- Message d'origine --------
Date : 25/09/2017 18:11 (GMT+01:00)
Objet : Re: [modeling-pmc] UML2 and Photon
Kenn,
That's pretty bad for Papyrus, parts of OCL, and parts of
EMF Compare. :-( And I'm not sure which other
release-train parts are downstream of those parts...
Downstream consumers should note that parts of UML2
(i.e., the generator parts) don't work with the latest EMF
(i.e., the generator parts of it) because any changes I
make to the GenModel (and I made many changes recently)
require UML2's extended GenModel to take action. So we
can't just feed the Oxygen version of UML2 into the Photon
train (at least not all of UML2's parts).
Regards,
Ed
On 25.09.2017 16:54, Kenn
Hussey wrote:
PMC,
I just wanted to give you a heads up that there are
currently no plans for UML2 to participate in the
upcoming Photon simultaneous release, due to lack of
funding. Unfortunately, this means that dependencies
will break when the aggregation file is disabled by
the EMO immediately following M4.
If anyone is interested (or knows someone who might
be interested) in helping ensure that UML2 is kept up
to date and that it can participate in the Photon
release, please reach out to me directly.
Thanks,
Kenn
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|
