Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321477

Summary: Documentation problems
Product: [Modeling] EMFT Reporter: Ed Willink <ed>
Component: MWEAssignee: Project Inbox <emft-mwe-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard:

Description Ed Willink CLA 2010-08-02 03:08:19 EDT
The MWE documentation is not installed when Xtext is installed into the Modeling EPP using the Modeling Discvovery UI.

The MWE documentation does not describe MWE2.

There is MWE2 documentation is in the the Xtext documentation.

The Xtext MWE2 documentation confused me:

The ResourceReader example extends WorkflowComponentWithSlot which in my impatience I mistook as a typo for WorkflowComponentWithModelSlot; it might help to provide the superclass first. At the end of the example it would be good to reference AbstractEMFWorkflowComponent, WorkflowComponentWithModelSlot and Reader and Writer.

The issue of paths (NB not pathes in some code) is glossed over by putting everything in the default package. It would be helpful to put class in a real package so that a real import statement is demonstrated.

The final StopWatch example answers the question as to how a bean file= translates to MWE2. It's just @. This deserves much more description.

There needs to be a much more substantial 'Javadoc' on components with one paragraph per parameter rather than half a sentence for selected parameters. It would be good to indicate how this extends to a growing library. For instance if MDT/OCL develops an MDT/UML2 MWE component for e.g. Package Merge, should MDT/OCL keep it private, should it contribute it to MDT/UML2 and wait for third party export, or should it be contributed to MWE. The latter seems the most useful.