eclipse-ocl-bot
commented
1 month ago By Christian Damus on Nov 20, 2009 09:09
OCL.ecore and OCLUML.ecore use the same templates because they both use the UML2 genmodel with its specialized/additional codegen capabilities.
The UML binding extends the MDT UML2 metamodel, which has its XyzImpl classes in an internal package. Because of this, the OCL component can't support extension of its UML binding metamodel, hence the @noextend and @noimplement annotations.
The EMF component also does not support extension of the Ecore metamodel, although it is not formalized in the way that MDT UML2 expresses this restriction. The OCL Ecore binding does extend Ecore, so probably it should also protect its clients by applying @noextend and @noimplement annotations. Of course, adding those now could be construed as API breakage, but the reality is that Ecore has always had this informal contract so this should be acceptable. In any case, it's only a metadata-incompatible change; it isn't a binary or source API incompatibility.
I would think that it is the unbound OCL.ecore metamodel that should support extension. That is exactly what, for example, the QVT languages need to do.
I agree with your comment about the copyrights in the templates, although I'm not sure that IBM should be the initial contributor. For any new artifact generated by a template, the initial contributor should be the person or company that generated it? Or, is that what you mean by distinguishing a "CVS default" and "customizing them for your identity?"
| --- | --- | | Bugzilla Link | 289275 | | Status | CLOSED FIXED | | Importance | P3 minor | | Reported | Sep 12, 2009 01:49 EDT | | Modified | May 27, 2011 02:54 EDT | | Version | 1.3.0 | | Reporter | Ed Willink |
Description
OCLEcore.genmodel uses o.e.ocl.ecore/templates and gives unconstrained annotations.
OCL.genmodel and OCLUML.genmodel use o.e.ocl/templates and give an @noimplement and @noextend annotation on all generated interfaces.
I do not understand why UML and Ecore are different.
We certainly do not expect any of these interfaces to be implemented so could make Ecore the same as UML, but it is only the unbound interfaces that are really not to be implemented so may be we make UML the same as Ecore. Whichever way we change requires an edit of one set of interfaces.
I favour adding o.e.ocl.uml/templates similar to the Ecore ones.
[Incidentally, these templates are the source of copyright notices for new auto-generated classes. You must customise them for your identity as original author. The CVS default is currently Zeligsoft. I propose to change the CVS default to Eclipse Modeling Project for new copyrights and IBM for initial contribution. I will transfer my copyright on new code to the Eclipse Modeling Project.]