[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-ocl.dev] Evolving plugin/feature names

Hi Adolfo

Would you like to put together a proposal for revised feature and plugin names and hierarchy, since your releng perspective gives you slightly different interests? 4.0.0 is a major version so we can totally reorganize if absolutely necessary - I hope not.

From a modeling perspective, a Feature contain Features or Plugins so a simple indented list is sufficient to identify the intended location of all plugins and features and Update Site Names.

feature X (Descriptive Name for X)
   plugin Y
   feature Z (Descriptive Name for Z)
      plugin A

For the sake of future proofing, assign names as if all plugins are promoted from examples now; we'll just defer renaming examples plugins until they are actually promoted.



On 03/02/2012 13:58, Adolfo Sánchez-Barbudo Herrera wrote:
Finally, I would like to remark (I've not thought about it) the importance of the new namespace from the point of view of another stakeholder: The releng :). It could be interesting to avoid problems like [1] or further changes in the releng stuff configuration to accomodate new plugins, having a "coherent" or "uniform" namespace to distinguish Core components from the Tools one.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=370347#c1

El 03/02/2012 12:03, Ed Willink escribió:
plugin and other global names
These obviously change. The simplest change is just delete ".examples". Do we want to do something else?
It would be nice if the event plugins went to EMF, but that doesn't look likely, so they too need review.
It would be nice to have names that can accommodate the pivot model sometime. I would like to try to partition the code into the run-time code that performs (re-)evaluation and the meta-run-time code that maintains the control objects that make IA so good. If this is possible, then we want corresponding names. Perhaps
I hope that migration of the run-time code to align with the code generated Java can be done quite easily, since the code generated Java makes no use of any form of the OCL meta-model; just the polymorphic Values and polymorphic Domain model for which there is direct and Reflective Ecore support. Perhaps
Migration of the meta-run-time code will be harder because that obviously makes use of the OCL meta-model. Perhaps
In order to avoid code duplication, code that is independent of Ecore/UML/Pivot should be in perhaps
It may also be appropriate to place some declarations independent of Ecore/UML/Pivot such as extension points in
We cannot easily use org.eclipse.ocl since that is highly Ecore/UML dependent.
NB being independent of Ecore does not prohibit use of EObject, EObject.eClass() etc. I hope that the external API facade can be Ecore/UML/Pivot independent and so in org.eclipse.ocl.common.impact.