TigerstripeF2F 20080716

< To: Tigerstripe Face2Face Meetings

Agenda was defined based on the proposed candidate topics below.

Topics

Versioning/distribution of generators on website

• The current download page for generators only shows the CVS which is inconvenient.
• We need to align releases with "versions" of the generators.
• Each generator should have a "src" flavor which would contain the source code of the generator, and a deployable flavor to be ready to be used.
• The current CVS HEAD still contains code compatible with the 0.3 release, and should be uploaded.
• Clever PHP is needed for the download page to avoid manual updates. Uploading the generators in a specific location should be enough.
  • Generators will live with their own version numbers, but a minimum version of TS will be stated.

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 to include packages on diagrams. This needs rebuild of diagrams onto GMF2.1, the risk associated means that this will not be included in the next drop (0.4), 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.

Status of UI Testing and inclusion in automated builds

• Project creation functionality (to quickly get to starting point for JUnit tests)
  • Jim to look at existing XMLImport code to either use or leverage logic
  • This functionality needs to be generic (not tied to UI code specifically)
  • Done for Alize release
• Refactoring testing
  • Test with Open and Close diagrams
• Associations
• Drag and Drop
• Annotations

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
  • Tigerstripe Template Design

• 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?).