RE: [wtp-dev] Java EE 5 models design overview

[Chuck Bridgham <cbridgha@xxxxxxxxxx>]

Hi,

I think its time for me to jump in and
offer a few suggestions for the EE5 models.
I think it makes sense to create a seperate
package for these models, but extend the existing J2EE models for a few
reasons.

- EE5 namespace includes legacy J2EE
elements
        Because
the new EE5 namespace includes the existing 1.4 elements, we can take advantage
of the existing models/EMF-DOM XML translators.
- Extending the model will help migration
scenarios.
- With the introduction of annotations,
the new extended model classes can be adapted using a "new" mapping
framework between a annotated JDT AST model  (Not JEM).

The existing J2EE models were originally
modeled from the J2EE 1.2 version of the spec (DTD's) using the Rose2Ecore
transformation tools.  These models were evolved as new
spec versions were published, being
careful that they were backward compatible, and using the XML translators
to "select" the attributes used by each spec version.

As Neil and Shaun have noted, the translator
framework has its limitations, and isn't well documented, and was built
primarily as a bridge between EMF and different XML models/parsing technologies.
Its not built to handle annotation mapping.


 By using many of the same techniques
Dali has implemented adapting their EMF model with the JDT AST model, and
refactoring out a mapping layer similar to the translator framework, adopters
could then
publish their own annotation processing
layer. WTP could create a reference implentation of this.  Also as
Neil states - the XML and annotation models don't match in all cases, and
seperate mappings will be required
to keep a comon EMF model in synch.

I agree JEM is not the direction we
want to take for modelling annotations.  This project has not committed
for making these enhancements.  Creating a model around the JDT AST
makes the most sense.
We also need to do more research regrading
the APT api's.  I know the Dali guys have some feedback here as well.

Its probably time for "someone"
 to gather all of these comments, and setup a meeting soon to discuss
further - ideas?

Thanks - Chuck
        
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)

"Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

11/15/2006 09:10 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc	"Stefanov, Tzanko" <tzanko.stefanov@xxxxxxx>
Subject	RE: [wtp-dev] Java EE 5 models design overview

Hi Jesper, 

We have taken a look at the J2EE 1.4 models implementation. It did make
impression that there are lots of hand made tweaks there. 

We decided to make the initial Java EE 5 models generated from the XML
schemas. There is also a lot of hand made work to be done to integrate
Java Annotations in these models. 

Can you outline in more details the tweaks that were done to the J2EE
1.4 models, so we have them in mind for the Java EE 5 ones? Do you think
better approach is to extend the existing J2EE 1.4 models with Java EE
5
specification instead of implementing separate Java EE 5 models?

Greetings
Kaloyan

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jesper Steen Moller
Sent: Tuesday, November 14, 2006 9:52 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Java EE 5 models design overview

Actually, the current J2EE models rely on hand-coded XML translation 
between the EMF and DOM model, using the nifty Translator framework. 
Making that work with an EMF model is done by hand, and not for the 
faint of heart.
However, it gives rewards with round-trip editing inside SSE and with 
the possibility of versioning the XML, e.g. for web.xml 2.2, 2.4.

We're using this framework in the Mule IDE - it is very powerful, but 
has its quirks.

-Jesper
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev