EMF Search Framework Extensibility---How It Works

There are two extensibility levels: Core & UI

- Core Extensibility only deals with search engine

- UI Extensibility deals with Search Page, Result Page

Overview

Here we will explain how extensibility things are working and how they have been architectured.

Firstly, given the fact this meta tooling framework is dealing with ecore based resources it was natural to design an extensibility around Ecore entities : EPackage, EClassifiers, EAttributes ... (mainly but not only).

The main idea is to be able to infer on EClassifiers from given EPackage in order to contextually evaluating queries against them.

One of the main goal extensibility was to be able to offer a general mechanism for EClassifiers meta element participants selection. It has been oriented by the need to selectively run query against a subset of EClassifiers meta element from a given EPackage.

Obviously, having several EPackages to consider in a tool forced to define extensibility accordingly. So, it was necessary to be able to present potential EClassifier meta element participants into independant EPackages separated form.

A search query in a pseudo mathematical form could be expressed as is :

QUERY (RESOURCE[], PARTICIPANT[], EXPRESSION) => RESULT[]

In our case we wanted to be able to propose configuration extensibility offering a selection configuration level like :

SELECTION (PACKAGE_1, ..., PACKAGE_i..., PACKAGE_k) = {{PACKAGE_1, {PARTICIPANT_1_1, ..., PARTICIPANT_1_n}}, ..., {PACKAGE_i, {PARTICIPANT_i_1, ..., PARTICIPANT_i_j}}, {PACKAGE_k, {PARTICIPANT_k_1, ..., PARTICIPANT_2_m}}

For instance :

SELECTION(P1, P2, P3) = {P1, {A,B,C}}, {P2, {D, E}}, {P3, {H}}

would be the configuration for queries only intestested on mentioned elements {P1.A, P1.B, P1.C, P2.D, P2.E, P3.H}.

We can notice that, selection according to package is probably easier for user while packages usually deal with same concern.