Community
Participate
Working Groups
Using a fresh Eclipse Modeling M7 platform. The Core SDK's feature description is not accurate: "Install this feature to parse and interpret queries on UML or Ecore models.Install this if you use a feature that depends on OCL (such as GMF) or if you want to work with OCL constraints or queries, want edit support, but do not need source code or documentation." - The feature doesn't provide any edit support at all. - The feature does really provide source code. Suggested text: "Install this lightweight feature to parse and interpret queries on UML or Ecore models. Install this if you use a feature that depends on OCL (such as GMF) or if you want to work with OCL constraints or queries. This feature provides the source code, but it doesn't provide any edit support or documentation".
The phrasing is not right, but not as wrong as you make out. "edit support" means EMF edit plugins not Xtext editors, so I would suggest. "Install this feature to parse and interpret queries on UML or Ecore models. Install this if you use a feature that depends on OCL (such as GMF) or if you want to work with OCL constraints or queries, want EMF edit support and source code, but do not need documentation." ---- While we're tidying up, can we change the feature name of org.eclipse.ocl.core.sdk from "OCL Core Extender SDK" to "OCL End-User SDK" org.eclipse.ocl.all.sdk from "OCL Extender SDK" to "OCL Core SDK" [I have never understood what 'Extender' means. "OCL Core SDK" is then the name that users actually see in the Update Site choice. "OCL End User SDK" is plausible as the intermediate parent of "OCL End User Features", but nobody sees this unless they browse the Update Site conformation.] ---- In category.xml.template Change "MDT/OCL features" to "Eclipse OCL features" since this is a top level description. The other releng ones are bureaucratic.
(In reply to comment #1) > The phrasing is not right, but not as wrong as you make out. "edit support" > means EMF edit plugins not Xtext editors, so I would suggest. > > "Install this feature to parse and interpret queries on UML or Ecore > models. Install this if you use a feature that depends on OCL (such as GMF) or > if you want to work with OCL constraints or queries, want EMF edit support > and source code, but do not need documentation." Ed, I agree that EMF keyword is helpful, but again you haven't not realize that the Core SDK only provides Runtime + Sources. The EMF Edit Support is provided by the org.eclipse.ocl.all.sdk feature. > > ---- > > While we're tidying up, can we change the feature name of > > org.eclipse.ocl.core.sdk from "OCL Core Extender SDK" to "OCL End-User SDK" > > org.eclipse.ocl.all.sdk from "OCL Extender SDK" to "OCL Core SDK" > > [I have never understood what 'Extender' means. "OCL Core SDK" is then the name > that users actually see in the Update Site choice. "OCL End User SDK" is > plausible as the intermediate parent of "OCL End User Features", but nobody sees > this unless they browse the Update Site conformation.] > > ---- I agree that we have an embarrasing selection of feature names and IDs. However, I wouldn't like to see "OCL Core SDK" name for the org.eclipse.ocl.all.sdk feature, when we have a different org.eclipse.ocl.core.sdk feature ID. I propose a different name IDs - Names: org.eclipse.ocl.all => OCL Runtime Features (Runtime is the name which receives the set which comprises the set of features and zips from our downloads webpage). org.eclipse.ocl.core.sdk => OCL Core SDK (Runtime + Sources a minimal SDK, ideal for language extenders ;P). org.eclipse.ocl.all.sdk => OCL End User SDK (Runtime + Sources + EMF Edit Support + Documentation, ideal for end-users). For Juno, we could try to incorporate a change/refactoring in names and Ids (We should check this with PMC), specially if we want to distinct between Core and Tools components/features. Now, we could also choose the word "OCL Minimal SDK" for our org.eclipse.ocl.core.sdk feature, so that we stop mixing the term core, which will turn into a wider/different concept the next release. > > In category.xml.template > > Change "MDT/OCL features" to "Eclipse OCL features" since this is a top level > description. The other releng ones are bureaucratic. Ok. Best Regards, Adolfo.
Currently: org.eclipse.ocl.all "OCL End-User Features" o.e.o+o.e.o.e+o.e.o.u Install this feature for the minimal support to parse and interpret queries on UML or Ecore models.\ Install this if you use a feature that depends on OCL (such as GMF) or \ if you want to work with OCL constraints or queries, but do not need source code, documentation or edit support. org.eclipse.ocl.core.sdk "OCL Core Extender SDK" o.e.o+o.e.o.e+o.e.o.u +Sources Install this feature to parse and interpret queries on UML or Ecore models.\ Install this if you use a feature that depends on OCL (such as GMF) or \ if you want to work with OCL constraints or queries, want edit support, but do not need source code or documentation. org.eclipse.ocl.all.sdk "OCL Extender SDK" o.e.o+o.e.o.e+o.e.o.u +Edit+Doc+Sources Install this if you plan to develop OCL-based applications. This SDK \ contains runtimes, edit support, documentation, and source code for OCL. So yes, I got confused. We cannot change feature-ids or their plug-in content for Indigo, so we just do the best we can for the descriptions. Runtime is better than End-User so let's have that change too. __xxx__ below for changes. org.eclipse.ocl.all "OCL __Runtime__ Features" o.e.o+o.e.o.e+o.e.o.u Install this feature for the minimal support to parse and interpret queries on UML or Ecore models.\ Install this if you use a feature that depends on OCL (such as GMF) or \ if you want to work with OCL constraints or queries, but do not need source code, documentation or __EMF__ edit support. org.eclipse.ocl.core.sdk "OCL __Runtime_ SDK" o.e.o+o.e.o.e+o.e.o.u +Sources Install this feature to parse and interpret queries on UML or Ecore models.\ Install this if you use a feature that depends on OCL (such as GMF) or \ if you want to work with OCL constraints or queries, __you want source code and documentation, but you do not want EMF edit support__. org.eclipse.ocl.all.sdk "OCL __Core__ SDK" o.e.o+o.e.o.e+o.e.o.u +Edit+Doc+Sources Install this if you plan to develop OCL-based applications. This SDK \ contains runtimes, __EMF__ edit support, documentation, and source code for OCL. "Core" isn't perfect, but it's not too bad. It's better than "Minimal" which isn't minimal since it's bigger than Runtime which describes itself as minimal. It may be best to leave "Core" as above for Juno and come up with new names to match the new namespaces.
Ed, Quite confusing your post... (In reply to comment #3) > So yes, I got confused. We cannot change feature-ids or their plug-in content > for Indigo, so we just do the best we can for the descriptions. Runtime is > better than End-User so let's have that change too. __xxx__ below for changes. > > org.eclipse.ocl.all "OCL __Runtime__ Features" o.e.o+o.e.o.e+o.e.o.u > Install this feature for the minimal support to parse and interpret queries on > UML or Ecore models.\ > Install this if you use a feature that depends on OCL (such as GMF) or \ > if you want to work with OCL constraints or queries, but do not need source > code, documentation or __EMF__ edit support. > The unique agreement. > org.eclipse.ocl.core.sdk "OCL __Runtime_ SDK" o.e.o+o.e.o.e+o.e.o.u +Sources > Install this feature to parse and interpret queries on UML or Ecore models.\ > Install this if you use a feature that depends on OCL (such as GMF) or \ > if you want to work with OCL constraints or queries, __you want source code and > documentation, but you do not want EMF edit support__. > I was not sure what you wanted to say with the underscore items. Now (after replying) I understand its purpose (the cursive), although you missed one underscore after "runtime" - Anyway: This feature description is incorrect, org.eclipse.ocl.core.sdk DOESN't contain documentation. > org.eclipse.ocl.all.sdk "OCL __Core__ SDK" o.e.o+o.e.o.e+o.e.o.u > +Edit+Doc+Sources > Install this if you plan to develop OCL-based applications. This SDK \ > contains runtimes, __EMF__ edit support, documentation, and source code for OCL. > > "Core" isn't perfect, but it's not too bad. It's better than "Minimal" which > isn't minimal since it's bigger than Runtime which describes itself as minimal. > > It may be best to leave "Core" as above for Juno and come up with new names to > match the new namespaces. Again, puzzled.... My "Core" suggestion was for the org.eclipse.ocl.core.sdk feature. It may be defined as a Minimal SDK since it contains the runtime + sources (I can't see any SDK without sources). If you again suggest the term "Core" to use the for the org.eclipse.ocl.all.sdk feature, it can't obviously be minimal, therefore, I don't not really know to which feature you want to attach the term "Core"... Anyway I'd be agreed if we used "OCL Core SDK" feature name for the org.eclipse.ocl.core.sdk feature ID. As said, I'm against to use "OCL Core SDK" for the org.eclipse.ocl.all.sdk feature when we already have an org.eclipse.ocl.core.sdk feature >.<. It'd be more confusing when it was compared with our download's web page which contains an Core SDK link (which matches with org.eclipse.ocl.core.sdk feature content). Have a look again to the following table (my proposal) which also includes correspondences with the downloadable zips from downloads web page (Of course this table will need to be changed/refactored in the next release): Feature id Feature name Zip name Downloads web page link name org.eclipse.ocl.all OCL Runtime Features mdt-ocl-runtime-3.1.0.zip Runtime org.eclipse.ocl.core.sdk OCL Core SDK mdt-ocl-CoreSDK-3.1.0.zip Core SDK (Runtime, Source) org.eclipse.ocl.all.sdk OCL End User SDK mdt-ocl-SDK-3.1.0.zip SDK (Runtime, Source, Documentation, Examples) org.eclipse.ocl.examples OCL Examples and Editors mdt-ocl-examples-3.1.0.zip Examples org.eclipse.ocl.master.all OCL ALL-In-One SDK mt-ocl-Update-3.1.0.zip All-In-One Update Site The only inconsistence here is the following: - The downloadable mdt-ocl-SDK-3.1.0.zip has extra "Examples" word in the corresponding downloads web page link (we would need to be remove it): The examples are not really included in the SDK zip (OCL End User SDK). Let's first agree with the feature names, after that, let's fix the feature descriptions. Regards, Adolfo.
This is much harder to discuss than describe. I think we're very close to agreeing, so commit what you think is best then if necessary we can discuss the residue.
Ok, As suggested, I've committed the proposal. I've also changed: - The category.xml template file - The edit feature and branding plugin, so that the EMF word it's also introduced in the feature name. Let me know any change we may consider (I should have created a patch rather than committing ;P, but it's done so...) Best Regards, Adolfo.
Downloads web page [1] and the wiki [2] have also been updated. [1] http://www.eclipse.org/modeling/mdt/downloads/?project=ocl [2] http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization
Resolving as fixed I guess there shouldn't be any objection / extra correction... otherwise reopen ;)
Closing all bugs resolved in Indigo.
