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.
Regards
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.
|
