Skip to main content
Jump to: navigation, search

Difference between revisions of "TigerstripeF2F 20080716"

(IPackageArtifact)
(IPackageArtifact)
Line 30: Line 30:
 
Need to include packages in the list of potential types for Dependency Ends.
 
Need to include packages in the list of potential types for Dependency Ends.
 
Note that the auditor currently rejects this as they are not java types.
 
Note that the auditor currently rejects this as they are not java types.
- Specify a tag to contain end type, and enhance persistor/extractor to use tag in future saves.
+
**Specify a tag to contain end type, and enhance persistor/extractor to use tag in future saves.
- Now need a better check for defined type as the java auditor will not be checking this.
+
**Now need a better check for defined type as the java auditor will not be checking this.
  
 
The auditor for Dependencies should check that if one end is a package, then BOTH ends must be.  
 
The auditor for Dependencies should check that if one end is a package, then BOTH ends must be.  

Revision as of 18:13, 16 July 2008

< To: Tigerstripe Face2Face Meetings

Agenda was defined based on the proposed candidate topics below. Ts-f2f-0708 agenda.jpg

Candidate Topics

Versioning/distribution of generators on website

Bugzilla review

XMI Import/export vs. UML import/export

Componentized model issues

  • Annotations in Tigerstripe generators: There was an issue where the generators were unable to access the annotation definitions due to the Eclipse class loading mechanism. A solution has been implemented where a developer may add annotation references in the TS-PLUGIN.xml file. This will ensure that the required annotation classes are available at compile time and runtime. This is implemented, but will need to verified in production.
  • Annotations in Facets: Enhancement to do inclusions and exclusions based on annotations is currently in progress. Functionality has been tested with JUnit, but not included in UI at this point. Facet xml file stores inclusion or exclusion patterns using annotation id (pkg + name of EMF class). An audit will be required.
  • Abstract Associations: Abstract Associations and abstract Associations Classes are not being walked through during facet resolution. If a concrete subclass is defined in a facet the abstract parent was also included if it is present in the same project. Now that we support generations requiring multiple components we don't necessarily see abstract parent (if contained in other component). This issue has been resolved and the generation will now walk associations between components.
  • Facet Meta-Data: Dynamic meta-data defined in facets to be accessible from generators (name value pairs). Generator would expect entries from facets and process accordingly (name + group of strings for first implementation).

There will be an integration build at the end of this week.

GMF rebuild

Diagram representation. Needs rebuild of diagrams onto GMF2.1, the risk associated means that this will not be included in the next drop, but we should prepare so that it can be done early in the next cycle.

Design needed for Packages and Containment - packages will be the only containers. Include Bugzilla for hyperlinks between diagrams.

"Complete" UI testing is required before attempting.

IPackageArtifact

Need to include packages in the list of potential types for Dependency Ends. Note that the auditor currently rejects this as they are not java types.

    • Specify a tag to contain end type, and enhance persistor/extractor to use tag in future saves.
    • Now need a better check for defined type as the java auditor will not be checking this.

The auditor for Dependencies should check that if one end is a package, then BOTH ends must be.

Review the API for containment in the API.


Adapters (Bug 240246) is resolved.

Package representation in class diagrams (GMF re-gen)

Status of UI Testing and inclusion in automated builds

Annotation API on IModelComponents

We have agreed to the following:

  1. There will not be a 'set' API on IModelComponent, but instead there will be a 'helper' class defined in Tigerstripe that performs the same tasks
  2. The 'get' API will remain but will befined on a new IAnnotationCapable interface in a new package ...model.annotation in the workbench.core plug-in
  3. The 'get' API will assume the "tigerstripe" scheme, and so scheme will not be passed through the API
  4. The following flavours of 'get' will be supported:
    • get...(String epackage, String eclass)
    • get...(String annotationId) - right-most match of epackage+eclass against supplied string
    • get...(AnnotationType type)
    • <T> T get...(Class<T> annotationClass) - matches all derived annotations of type and of sub-type
  5. There will for each 'get' be a corresponding 'has' to return a boolean value

Generic Model Support

  • Templates
  • Annotation rendering on UI
    • Icon provider is done.
    • Need Decoration Provider that works throughout UI
      • We need to cover Diagram and Explorer, so maybe able to extend Eclipse standard Decoration providers to be included in Diagram.
    • Annotation rendering on Class Diagrams is "functional" but not pretty.
  • Diagram Generation
    • Still need not sure whether GMF diagrams can be rendered as pictures when running Eclipse Headless.
    • Would be nice to have hyperlinks in pictures. Tried SVG output, and it doesn't work properly (colors?).

Back to the top