Community
Participate
Working Groups
In Bug 360072 the built-in delegate URI bindings were inflexible suggesting that a user selection should be permissible. Another built-in selection is the URI emitted by the OCLinEcore editor/pivot2ecore translator. ---- For existing Parsing/Evaluator options, users/applications must use Java poking. This is inconvenient when using QVTo that fails to suppress the 'non-standard closure' warning. Providing per-project/workspace settings seems helpful. ---- The current Xtext editors use a communal OCL Preference page to avoid cluttering the top level entry. This is currently a dummy page defined by the Essential OCL plugin. An independent plugin is needed to provide a communal root for all editors and possibly the console(s) and .... ---- Suggest introducing an org.eclipse.ocl.ui plugin for these pages. Since it's a new 'core' plugin, I think it can go straight in as non-examples. It's probably easier to discuss content by reviewing a prototype. For each option, there is a compromise between giving the users flexibility and giving them freedom to do something stupid.
branch bug/360354 has an implementation with Workspace and project-specific pages for all options except: - class-valued options - needs an Object browser FieldEditor Use of Workspace options as the defaults when an OSGI PreferenceService is available. Still to do: a FieldEditor for class-valued options foldable sections like the JDT compiler options use of project-specific options as the defaults ?? How can the IProject be discovered from an EvaluationEnvironment, BasicEnvironment ?? A new setProject API is possible but wouldn't be in use by OCL-based tools. For an EvaluationEnvironment, the IProject containing the context object might be a plausible guess. For a BasicEnvironment the contextProperty/Class/... may be plausible. So I suggest a new setProject API for applications that are prepared to specify it, and a fallback to the project of the context otherwise. The workspace defaults are determined by the built-in defaults so the only compatibility hazard I see is when a spurious project that specifies project-specific preferences manages to confuse another OCL activity, but that spurious project must be new functionality, so it's not a legacy usage.
An updated contribution is available in the bug/363639 branch.
On master for M6.
CLOSED after a year in the RESOLVED state.
