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

EGF/IndigoReview

< EGF
Revision as of 05:09, 27 July 2011 by Benoit.langlois.thalesgroup.com (Talk | contribs) (Schedule)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Logo EGF.png


This page provides the required Docuware for the EGF v0.5.0 Release Review, as part of the upcoming Indigo Simultaneous Release.

Overview

EGF (Eclipse Generation Factories) is an Eclipse component project in incubation under the EMFT project.

Its purpose is to provide a model-based generation framework, especially to automate software production.

Its objectives are:

  • Supporting complex, large-scale and customizable generations
  • Promoting generation portfolios in order to capitalize on generation solutions
  • Providing an extensible generation structure


Features

In this release

For the first time, EGF is part of an Eclipse Simultaneous Release. The different features provided by EGF v0.5.0, as part of Indigo, are of two categories.

EGF Engine

The EGF Engine defines the core model of EGF (e.g., task, factory component, or pattern) and provides core behaviors of EGF (e.g., dynamic execution). Extending the core model and behaviors is the first type of EGF extension. For instance, to conduct a generation, EGF enables to support Java tasks; EGF was enriched, later by contribution, to support Ant tasks.

EGF Portfolio

A generation portfolio is a consistent set of factories with the objective to meet a generation topic. A generation portfolio is the second means to extend EGF. It is valuable for development teams, as a form of capatilzation, and for portfolio users, by providing off-the-shelf factories.

The EGF project provides two default generation portfolios:

  • The first one is an enhancement of the EMF Generation which enables to customize the EMF generation.
  • The second one is a build chain portfolio which enables to configure a build chain (with an EGF build editor) and to generate all the scripts for a build platform, i.e. Hudson and Buckminster today. For instance, the EGF Helios and Indigo build chains are realized with this portfolio.

Accordance with project plan themes and priorities

The priorities are the following:

  • Improving the foundations of the EGF engine
  • Providing two portfolios (i.e., enhancement of the EMF Generation, build chain portfolio) in order: 1) to provide a more substantial EGF component, 2) to provide the Eclipse community with valuable software factories, 3) examplify how to develop and use generation portfolios

See http://www.eclipse.org/projects/project-plan.php?projectid=modeling.emft.egf

Non-Code Aspects

The complete EGF documentation is available from the EGF Wiki page:

  • Project's general information
  • Documents and presentations
  • Tutorials and use cases
  • Download information
  • Portfolio information
  • Complementary resources and useful links

APIs

The EGF Javadoc is available here (from the Indigo build).

Architecture

The general architecture of EGF is: 1) the EGF Engine extended by Engine Extensions, 2) extended by a set of generation portfolios.

The development process below displays how portfolios can be iteratively combined to create new factories and extensions.

The example below of an EGF factory shows a factory component which combines invocations to heterogeneous languages (e.g., Java, Ant, Jython) and tools (e.g., Jet, ATL) but homogeneously integrated in the framework of EGF.

EGF-Architecture instantiation.PNG

Testing & Packaging

EGF uses a Buckminster-based system to build and promote versions.
Each new build is tested at least with Eclipse 3.7 (Indigo).
Core plugins are provided with dedicated test plugins checking their valid behavior.
EGF is integrated into the Indigo Release Train since the M3 release.
EGF is also part of the Amalgamation Modeling Package for Indigo.

End-of-Life

No EGF component is deprecated so far.

Bugzilla

EGF bugs can be found here on Bugzilla.

Standards

EGF does not implement any standard.

UI Usability

EGF intends to conform to the User Interface Guidelines.

Schedule

EMFT EGF is a "+3" project in the simultaneous release

Schedule respected by EGF is the following:

  • M3 11/10/2010
  • M4 12/15/2010
  • M5 02/02/2011
  • M6 03/16/2011 (API Freeze)
  • M7 05/04/2011 (Feature Freeze)
  • RC1 05/18/2011
  • RC2 05/25/2011
  • RC3 06/01/2011
  • RC4 06/08/2011
  • Indigo 06/09/2011
  • RC2_SR1 08/29/2011
  • RC3_SR1 09/05/2011
  • RC4_SR1 09/12/2011
  • Indigo_SR1 06/23/2011


Communities

EGF simultaneously: 1) joint Amalgam, 2) joint the Indigo release train, 3) started to blog on PlanetEclipse to promote EGF and EGF portfolios. Stats, from March 2011, confirms an average rhythm of 12/13 downloads of EGF a day.

IP Issues

The Eclipse IP Process has been strictly followed and all plugins contain the appropriate about.html and license files.
The EGF IP Log is available from http://www.eclipse.org/projects/ip_log.php?projectid=modeling.emft.egf EGF is released under the EPL licence.

EGF provides integration with languages and tools. Some of them are developed under the EPL licence (e.g., Acceleo, ATL) but others are incompatible with the EPL licence (e.g., Jython, JRuby). In order to fix this type of IP issue, EGF only provides integration with languages and tools respecting the EPL licence. For the other ones, a specific EclipseLabs project, the EGF portfolio project, was created to isolate and manage licence incompatibility.

Project Plan

The current project plan is available from here. Graduating to v1.0.0 for the Juno Simultaneous Release is planned. This next EGF version would include:

  • Improvement of the general quality of the existing components (e.g., bug fixing, user facilities)
  • Improvement of the generation workflow (sequential today)
  • Extension of the "Enhanced EMF Generation" portfolio to take into consideration topics such as CDO
  • Demonstration of the ability to support families of generations (with the target of supporting product lines later)
  • Increase of the scope of integration of new languages and tools for interoperability in the generation workflow

Back to the top