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

(Ideas)
m (Intro)
Line 1: Line 1:
 
= Intro =
 
= Intro =
This is proposal page for GSoC idea "DSL and Model-Driven Generator for EclipseLink" from [Google_Summer_of_Code_2009_Ideas]
+
This is proposal page for GSoC idea "DSL and Model-Driven Generator for EclipseLink" from [[Google_Summer_of_Code_2009_Ideas]]
  
 
= Project Title =
 
= Project Title =

Revision as of 07:10, 4 April 2009

Intro

This is proposal page for GSoC idea "DSL and Model-Driven Generator for EclipseLink" from Google_Summer_of_Code_2009_Ideas

Project Title

Textual DSL and Model-Driven Generator for EclipseLink with Xtext

Project Summary

Create a textual DSL for EclipseLink that consist of:

  • Xtext grammar for describing JPA Entities
  • Enhanced editor for that grammar
  • Xpand based generator of EclipseLink code for entities and additional resources

Detailed Description

My vision is to create syntax for DSL that is exactly derived from annotations so users should see exact mappings between Java code and DSL (e.g. annotation names would be keywords in grammar). It would just abstract information from syntatic noise (remove getters, setters, public keywords, similar to how Groovy handle POJO) and use convention where possible. This way user don't have to learn another language. It would be also easy to add new functionality to grammar in future this way.

Grammar could also try to provide some syntactic sugar, so that it would not be needed to write "@OneToMany List<Author> authors" but for example "Author authors*". That would be examinated later in the project after the scope is set.

I plan to learn more about EclipseLink and define the scope for the EclipseLink DSL with help of mentors and community. I have question to ask, but I have to gather some additional knowledge to ask the right questions.

There are things that can be included in scope after examination and feedback:

- Support for JPA 2 - JPQL support (editor would understand JPQL when editing named queries etc.) - support for generating xml mappings - support for custom setters, getters and additional Java code (derived properties) - support for bootstraping / reverse engineering existing JPA entities to DSL

I have experience in reading java source with JDT and Xtend, so features like using linking to exisitng Java entities in Xtext grammar or reverse engineering can be created by me if I found it valuable.

EclipseLink provide ANTLR grammar for JPQL and it seems possible to port this grammar to Xtext. It could be a good selling point for DSL but I have to examine EclipseLink example projects first.

The main risk is that I need to gather more knowledge about JPA and EclipseLink to create good DSL and that will need some time. The risk would be reduced if good example projects exists.

Ideas

Things to think about later/

  • Support for JPA 2
  • JPQL support (editor would understand JPQL when editing named queries, this way derived properties can be created too etc.)
  • support for generating xml mappings
  • support for custom setters, getters and additional Java code
  • support for bootstraping / reverse engineering existing JPA entities to DSL
  • annotations in dsl

Annotation are not needed in metamodel as EMF has support for it, but it would be nice to have a way of adding data to model for some special cases. This way it would be easy to specialize templates as well as reuse dsl as intermediate model in other use cases and make it future-proof. It would be possible to create full roundtripping with usage of annotations in dsl or even migrate other presistence entities to EclipseLink and refine it later.

Back to the top