Community
Participate
Working Groups
A common Eclipse idiom is that a project with an XXX nature has an XXX builder that builds (or maybe just validates) *.xxx files within that project so that the Problems View Markers and Package Explorer icons give an overview of the XXX issues in need of attention. There is no UML nature so bad *.uml files are only detected interactively by opening the file and validating. The advent of Ecore EAnnotationValidator support allowing embedded OCL to be validated offers new opportunities and difficulties. See Bug 528869. Suggest that a UML nature and builder might use a similar queue-to-a-validation-job as is being adopted by the OCL nature and builder. Ideally some form of Bug 427152 body-specific Constraint validation would allow validation of a *.uml file to validate all embedded content too.
In the absence of a uml.ui plugin, I could easily clone the new OCL support as a uml.edit plugin contribution.
(In reply to Ed Willink from comment #1) > I could easily clone the new OCL support as a uml.edit plugin contribution. But without some form of Bug 427152 solution, a clone will make my OCL coding unnecessarily hard. If a UML nature/builder validates UML specification elements only, the OCL (and ALF) nature/builder are needlessly complex with a partial validator avoiding duplicating UML diagnostics. If a UML builder/nature validates all *.uml elements, using an extensibility mechanism for OCL/ALF, then OCL/ALF nature/builders are simplified; they ignore *.uml and consider only *.ocl/*.alf. (Whether to validate Ecore elements is probably a project preference defaulting to ignore since for OCL and presumably ALF the UML-hosted bodies are the primary definitions, the secondary copies embedded in Ecore may conflict and be differently relevant to different users. If nothing else, creating 10 distinct OCL pivot models for 10 distinct stereotype definitions will really burn validation time.) (Selective validation of *.xmi/*.xml files may benefit from some EMF/platform level support to ensure that the nsURI can be peeked and cached once rather than computed many times by many tools.)
The new OCL builder supports fileExtension and filePath filtering. Users may edit the default content: <buildCommand> <name>org.eclipse.ocl.pivot.ui.oclbuilder</name> <arguments> <dictionary> <key>disabledExtensions</key> <value>*,essentialocl</value> </dictionary> <dictionary> <key>disabledPaths</key> <value>bin/**,target/**</value> </dictionary> <dictionary> <key>enabledExtensions</key> <value>ecore,ocl,oclinecore,oclstdlib,uml</value> </dictionary> <dictionary> <key>enabledPaths</key> <value>**</value> </dictionary> </arguments> </buildCommand> *.ecore and *.uml are enabled by default giving a conventional Eclipse markers behaviour when the OCL nature is applied to a project. The markers created by a *.uml save are deleted and replaced by markers from the OCL validator, which occurs in a separate ValidationJob to avoid the BuildingWorkspace job locking out the user for every UML/OCL/Ecore validation. Once UML provides its own builder, the OCL remedial configuration should be revisited.
