Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Revised features

Hi Laurent

I took the opportunity of the UML 5.0 version number ripples to clean up the features a bit.

It has always seemed a little unhelpful that our first appearance is:

what is an End User or Core SDK?

After a major battle with Buckminster (all  my own fault...) we now have

I opted for "Unified" to hide Pivot in very high level contexts.

OCL All-In-One is obvious - no change
OCL Classic gives Console and impact Analyzer too.
OCL Unified is all pivot facilities but no Ecore/UML (I fixed a stupid bogus dependency and NPE)
OCL Examples and Editors is redundant but referred to in too many documentation places

All old features still exist, it is the top level view cherry pick and titles/descriptions that is better. All features can be accessed in flat mode.

New underlying features
org.eclipse.ocl.examples.classic (all Classic)
org.eclipse.ocl.examples.unified (all Pivot)
org.eclipse.ocl.examples.unified.core (all Pivot without UI)

I cannot see a strong justification for an intermediate Pivot with only half the UI (Complete OCL+Console but not OCLinEcore/OCLstdlib) once you start taking Xtext you're comitted to bloat anyway.


        Ed Willink

On 20/01/2014 13:04, Laurent Goubet wrote:

> Laurent: You were going to provide a new OCL (exampes) feature hierarchy. When I thought about it I end up with nearly one feature per plugin. Maybe you can provide a more sensible half-examples.

I thought that the features were hard to understand and that it was a shame that we couldn't install your new, improved OCL without installing all of the examples along with it. I never took the time to try and outline something that would be better though.

You had answered with something like this :

E&E into E&E { Classic {IA, Console} , Pivot { RunTime, CodeGen, UI { EssentialOCL, CompleteOCL, OCLinEcore, OCLstdlib, Console }}, Examples}}

I really don't think that including "Pivot" anywhere is a good move. Users wouldn't understand what that means in the context of OCL. Then again ... I don't really see how to properly split the "old" and "new" OCL. Maybe by renaming the "old", "legacy" and using the "OCL" label only for the new implementation (pivot)?

It is hard to properly isolate a set of features per functionality in the current "examples" folder; not to mention that the pivot has a dependency towards the o.e.ocl.examples.common which in turn depends on o.e.ocl.ecore... further blurring the line between pivot and legacy ocl. Before trying to define a set of features, I think it would be wise to properly determine the line between the two implementations : is the pivot totally independent from the legacy ocl (which I initially thought to be the case), or does it really depend on parts of the legacy code? Shouldn't these parts be copied in the pivot code if so? Couldn't the pivot, essentialOCL, CompleteOCL and OCLInEcore be moved in a separate folder (maybe "pivot" since this is only seen on the repository?) instead of being left in the examples folder?

Anyway, I think that a set of features that users could really understand would be something of the sort :
  • Classic/Legacy OCL (Maybe excluded from the Luna aggregator? Users don't have to install the old OCL, and those who depend on it won't have to manually install the plugins anyway... This may break other luna contributors though if the plugins can't be found in that update site)
  • OCL core (containing only the non-ui parts... the bare minimum set of features to compile and evaluate OCL expressions. EssentialOCL and CompleteOCL are probably part of that. Basically, a user should be able to install the CompleteOCL editor in one eclipse, then copy the ".ocl" file in another anvironment that only has the OCL core install and still be able to evaluate the constraints it contains.)
  • OCL UI (I think this should include the CompleteOCL editor as well as the console)
  • OCL in ecore (with OCLInEcore and its dependencies. I think this one should be separated since 1- it can be and 2- it can cause issues (it once replaced the "default" ecore tree editor by yours ... which is really bad in a user point of view. The feature description should make it obvious what "ocl in ecore" means and what the users will gain by installing it)
  • OCL Examples (for what really are examples of use... royalandloyal may be the only one though? I think it would be nice to have an example using CompleteOCL and another using OCLInEcore... EssentialOCL is probably better left to the Console, which I don't see as an examples, it should be a part of the "OCL UI" feature that provides functionality to the user.)

Bear in mind that this is only seen from a user point of view. I have been too far from OCL for too long a time to really have a "high level" point of view of all the different functionalities you now provide.

Back to the top