Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Java EE 5 models design overview

Hi,

I want to thank for all the replies. There were lots of things that
become clearer to me. 

I agree with the suggestion to organize the discussions. So, Naci,
please do as you suggest. 

Greetings
Kaloyan

-----Original Message-----
From: Naci Dai [mailto:naci.dai@xxxxxxxxxxxxx] 
Sent: Thursday, November 16, 2006 6:16 PM
To: General discussion of project-wide or architectural issues.
Cc: Stefanov, Tzanko; Chuck Bridgham; Raev, Kaloyan
Subject: Re: [wtp-dev] Java EE 5 models design overview

I can take the lead to coordinate and facilitate this discussion.  I 
think it makes the most sense to setup a focus group to plan the work. 

May I suggest that at least we should have the participation of:

Chuck Bridgham  - As the Component and Tech Lead for the EE5 Models
Neil Hauge  - Mapping Annotations
Kaloyan Raev - Adopter/Contributor
And other interested parties.....

I will prepare an agenda based on the discussions and suggest 
alternatives for the meeting calendar


>
> 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
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>   


-- 
Naci Dai,

eteration a.s. 
itu teknokent ari-1 25
Maslak, Istanbul 34469

+90 (533) 580 2393 (cell)
+90 (212) 328 0825 (phone)
+90 (212) 328 0521 (fax)
http://www.eteration.com/
mailto:naci.dai@xxxxxxxxxxxxx



Back to the top