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: [EMAIL PROTECTED]
Phone: 919-254-1848 (T/L: 444)
"Raev, Kaloyan" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/15/2006 09:10 AM
Please respond to
"General discussion of project-wide or architectural issues."
<[email protected]>
To
"General discussion of project-wide or architectural issues."
<[email protected]>
cc
"Stefanov, Tzanko" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
