Migration

From Furcas Wiki

Jump to: navigation, search

FURCAS Migration

- Reorganize our code. See PackageArchitecture

- Editor Framework (10 PD) (->?)

* Remove MOIN Model Editor Framework dependencies
* Look at EMF.Edit generated default editors and their use of editing domains and resource sets
* Trees? What about icon repository, property view integration
* Have a look Eclipse IMP for the generation of syntax highlighting stuff etc.
* Migration questions and todos:
** How to handle MarkerManager, this was formerly done by MOIN, needs to be reimplemented?! (registration of interface MarkerRefreshListener)

- Prettyprinter (10 PD) (-> Stephan)

* Backtracking also from inner elements towards outer elements
* Use events to trigger pretty-printing when necessary
* Always run pretty printer to validate FURCAS

- Incremental Lexer (2 PD) (-> Thomas) (done, needs more tests)

 * Remove position/offset handling from lexer code (still todo)

- Incremental Parser (2 PD) (-> Thomas) (done, needs more tests)

 * model partition assignment (still todo, see partitioning branch)

- Textblocks-Metamodel (2 PD) (->Discussion, all)

 * Migration to Ecore
 * Embed / use OCL metamodel
 * remove offsets by and large
 * focus on non-redundant information not otherwise available in domain model

- OCL Prepared Expressions (5 PD) (-> Axel (largely done; see com.sap.emf.ocl.prepared))

 * OCLExpression + Wrapper with reference to a LiteralExpression
 * Ensure proper synchronization once a replacement of expressions parts takes place

- Model Adapter (5 PD) (-> Armagan + Thomas) (done)

 * Port MQL queries to query2/MQL on EMF
 * Port model access

- CtsTextDocument (1 PD) (->Armagan)

- GlobalDelayedReferenceResolver (20 PD) (-> Axel?)

  • Refactor DelayedReference, DelayedReferenceHelper, IncrementalReferenceEvaluationRegistry

First of all, the various different types of DelayedReferences (simple property init, query-based property, foreach, and semantic disambiguate) will be spread across a number of subclasses of OCLBasedModelUpdater. Even though eventually these will have to become Triggerables (triggered by the OCL IA), for now they will just be used by the ObservableInjectingParser and not by the IA. We should for now remove all OCLExpression references from the TCS metamodel as we have all these issues with #context, #foreach and the ? substitution in queries. Instead, we leave the OCL expressions in the TCS mapping model as text and convert them at the latest possible moment into OCLExpressions. Use the existing ContextAndForeachHelper functionality to find and parse the #context.oclAsType(...) stuff to infer the context type for the OCL parser accordingly. All this will then hopefully result in a port of the existing, somewhat flawed functionality with #context, #foreach and the ?-parameterized queries, all without OCL IA support for now.

  • Solve the issue with parameterized query expressions and impact analysis. Options currently discussed:
    • replace parameter by expression that navigates to token in text blocks model (complicated, but may work generally and without cloning the expression, also for those not currently loaded in any editor)
    • create a new expression for each query occurrence (simple, but probably misses elements outside any open editor)
    • patch the expression such that impact analysis doesn't try or at least doesn't succeed at a partial evaluation of the parameter expression (simple, but misses opportunity to shortcut impact analysis based on a value comparison and partial evaluation)
  • registration of OCL expressions with event manager

- Editor and Language Test-Framework (5-10 PD) (=> Students)

 * Zipping of projects in runtime workspace and loading into JUnit workspace
 * Maybe easier than with MOIN due to connectionless model load

Total estimated migration effort: ca 45-50 PD

Personal tools