Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "TigerstripeF2F 20080716"

(IPackageArtifact)
(Generic Model Support)
 
(5 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
[[Image:Ts-f2f-0708 agenda.jpg]]
 
[[Image:Ts-f2f-0708 agenda.jpg]]
  
== Candidate Topics ==
+
== Topics ==
 
==== Versioning/distribution of generators on website ====
 
==== 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.
 +
 
==== Bugzilla review ====
 
==== Bugzilla review ====
 
==== XMI Import/export vs. UML import/export ====
 
==== XMI Import/export vs. UML import/export ====
Line 19: Line 26:
 
==== GMF rebuild ====
 
==== 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.  
+
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.  
 
Design needed for Packages and Containment - packages will be the only containers.  
Line 30: Line 37:
 
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.  
Line 40: Line 47:
 
Adapters (Bug 240246) is resolved.
 
Adapters (Bug 240246) is resolved.
  
==== Package representation in class diagrams (GMF re-gen) ====
 
 
==== Status of UI Testing and inclusion in automated builds ====
 
==== 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 ====
 
==== Annotation API on IModelComponents ====
 
We have agreed to the following:
 
We have agreed to the following:
Line 56: Line 72:
 
==== Generic Model Support ====
 
==== Generic Model Support ====
 
* Templates
 
* Templates
 +
** [[Tigerstripe Template Design]]
  
 
* Annotation rendering on UI
 
* Annotation rendering on UI

Latest revision as of 13:51, 18 July 2008

< To: Tigerstripe Face2Face Meetings

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

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.

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 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

  • 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