Abstract and Extract Existing Feature Trace Infrastructure

[pmbittner]

Currently, feature traces are implemented as de.tubs.variantsync.core.utilities.IVariantSyncMarker. Such a marker represents an individual mapping for a single chunk of text in a text file (?). To this end, it is represented by an int offset describing the index in the text of the document at which the mapping begins and an int length and the corresponding feature formula (given as a string).

To alternatively replace this (deprecated) representation of feature traces, we first have to introduce interfaces to make the GUI independent from the actual representation of feature traces.
Therefore, follow these steps:

• Identify where, how, and why IVariantSyncMarkers are used. Where are these stored (in code as well as on disk)? Where is the place where they are linked to the files? Which views displays the markers? Are there any Eclipse dependencies? ... Document your findings with Javadoc and sketch them (e.g., on paper).
• Depending on what you found, try to abstract and extract all infrastructure on the markers that does not depend on eclipse to the new library. (Dependencies to the FeatureIDE library are fien as we will use that in the VariantSync core library, too.) To this end, come up with suitable interfaces such that the GUI can still communicate to / work with the markes but is independent from these. In fact, the GUI should deal with feature traces that can be realized as markers or with an instance of your AST<LineGrammar, String>. (Later we want to generalize this to AST<G,V> but for now we should keep things simple).
• Find a suitable place in the VariantSync Eclipse plugin where you can provide instances for your interfaces. Use the implementations you moved to your library.
• Make sure your extraction was a refactoring: Test that VariantSync still behaves as before (at least as shown in the screencasts such that these can be reproduced).