View source for Minutes of the JEE 5 Working Group meeting Nov 30, 2006

== Teleconference on [[JEE 5 Support]] in WTP - Nov 30, 2006 ==
=== Attendance ===
*Bob Frost
*Shaun Smith
*Tim Wagner
*David Williams
*Larry Isaacs
*Chuck Bridgham
*Paul Fullbright
*Neil Hauge
*Karen Moore
*David Gorton
*John Goodman
*Brian Vosburgh
*Kaloyan Raev
*Max Andersen
*Naci Dai
and more....

=== Minutes ===
* ND:  Welcome to the first call of the JEE working group.  We will repeat this call weekly to track progress of the implementation.  Working group is composed of the component owner who will lead the implementation.  Today we have a wider audience.
* ND:  We will start with a review of the discussion summarized in http://wiki.eclipse.org/index.php/JEE_5_Support.  To start with lets review what is planned in WTP 2.0 for JEE 5 support.  David can you comment on JSP/JSTL support?
* DW:  There will be some JSP support for JEE5 for WTP 2.0.  Details are not clear but there is some work
* ND:  How about JSTL?  I know Raghu was interested in this for JSF.
* No answers .... Raghu not online
* ND: Neil, Can you comment on JPA and EJB3 status?
* NH: Dali projects covers the JPA spec. The rest of EJB 3 is not in its scope.  There is some work that can be used for EJB3 like our way of handling metadata but we do not support session beans.
* CB: Neil, I know that you have built utilities to handle two different sources for info: Annotations (metadata) and XML descriptors for the model.  We are also interested in supporting both sources in JEE 5 models.  I think a common layer can be extracted from Dali and contributed to JST.  What are your recommendations?
* NH: I can say(hope) that a common model can be defined for both sources.  What we found is things are very different for these sources.  Especially, the behavioral content is very different (descriptors are quite different).  They are not very clean. That has caused a lot complexity. Annotation do not support everything in the descriptors + model have to act differently for defaulting - i.e. defaults specs vs java model.
* PA: For example containment behavior is different. In XML you start with a mapping, and in the mapping you spec a class.  In java you start with class and do the mapping.
* BV: Another problem is that both models (XML and Annotations) are too flat for tooling purposes.
* CB: We should start talking about solutions to these problems. Thanks to SAP for their contributions. The SAP proposal made us look at how to extend the models.  We have to be forward thinking about how to extend the models for future version i.e JEE6.  JEE5 is so different that we need to separate it cleanly from the existing models. We need interfaces between Java and XML models.  That way we may not need to change the models, which is very important for backward compatibility.  We can add interfaces as needed.
* MA:  Is any of this will be  in WTP2.0? WTP 1.5.2 is not EJB3 friendly.  We need a release of WTP 1.5 that does not complain about EJB3 for JBoss IDE.
* DW: I do not want to sound pessimistic. But we will see what can do. But not sure we will be able to do it in 1.5.3.
* CB: I do not think it is a good idea to change the existing models. J2EE is currently hard coded in the models. The models do not  not recognize the JEE 5 versions and namespaces. We can create a patch so that the namespace can be handles, all legacy models will be included but anything new will not be recognized. Any work beyond that  will be in 2.0
* CB: What are your thoughts on having model interfaces does not have dependencies on EMF.  We can have a another set that has the old style interfaces with EMF dependencies.
* DW:  I support that. Reducing the coupling is better
* CB:  EMF provides things like notifications etc.  We can provide overlapping/alternate interfaces
* PF:  EMF very slanted towards XML, not natural to use in Java sometimes
* CB:  Neil, you also have done work to extend AST in JDT with annotation utils. Any plans to push that into a common layer.
* BV:  No plans
* CB: We are very interested in having that contributed to a common layer too.  That work is very useful for all kinds of other things.
* BV: JDT has very little. That work allows us to manipulate annotations, ignorant of types of annotations, it provides all the sugar on annotations.
* DW: These looks like good places to start. I suggest we find things like that and open a patch to move them to a common layer.  And iteratively see if this can be done.
* SS:  There is a lot of support in Dali for editing and validating annotations.  I can build EJB3 sessions.  Of course, WTP does not recognize them as EJBs.  To start with we probably do not need any EJB3 editing tools and wizards.  I need validation deployment support.  The simple case is just to package them and deploy them.  Do not worry about descriptors.
* CB:  I would like to propose tro extend the existing model to handle XML, recognize the new name space (use the old elements), then start contributing the new plugins as an extended plugins.  In phase 2 we can start looking at the annotation model.  I am not sure when thi scan start (if at all for WTP 2.0). When we add the support for the namespaces, we can tolerate the EJB3 descriptors.  Extended tools would work.  I cannot commit to it now.  We will start with enabling the JEE 5 models.  This work will probably go on after Jan7 (two milestones left) M5 is before eclipsecon.
* DW:  Ideally we should be done 80% done for M5, M6 should be done and ready to start the end game.
* CB: What are peoples thoughts on making these changes  - old models and new namespace?
* DW:  I would caution against that changes: 1) Any temporary changes will become permanent. 2) If not needed for WTP  I am against it. But we can provide patches. We should do this incrementally.  There are too many unknowns.
* BV: You cannot do much with XML without knowing about annotations, so these are temporary changes
* MA: Pure EJB project, you do not need too many descriptors.  It is easier.  Now, WTP 1.5 tooling says you have to be complex.  To start with we should think what is the minimal for support for EJB3.
* ND:  We can probably support EJB3 facets, other specific JEE 5 facets and simple projects.  If you have done it for JBoss IDE, rre you interested in contributing that?
* MA: We could, they are quite simple.
* SS: A word of caution.. Even with simple projects, we must support the old style descriptors so it will not be that easy.
* MA: Maybe we should start with simple case.
* SS: That is what we start in Dali, we will add complexity later.  That is the common use case. Transactions semantics and defaulting is very similar to DALI
* CB:  Enablement you are speaking of does not require XML. That is what we are trying to get away from
* MA: JBoss IDE EJB3 support is a facet, if we can handle that we will be done.  There are some deployment limitations and specific problems, I will send to Chuck.  Hard coded things and stuff make it hard.
* CB:  This will be good, because this will get us started with an easier use-case that we can work it.
* DW: We should talk about this focus group.  It should be limited to people who are working on the code and should be focused on JEE5 support task.
* ND: Agreed.
* CB: We should use the wiki to start adding comments and minutes.  By next we should start talking about a plan and what to do for the milestones.
* DW: Focus group should be working on the code.  For others we can update status and plans.
* ND: Thanks for attending.  The notes will be available at the wiki.  We will meet next week.

=== Comments ===

These are post meeting comments from:

* Kaloyan Raev
As you remember I have already submitted a patch in the Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=157185
 
The goal of the patch is to make WTP Java EE 5 friendly. With the patch it is possible to create valid Java EE 5 projects and deploy them on Server Runtimes that are Java EE 5 compatible. Everything is very basic, but it makes possible for the user to develop Java EE 5 application with WTP.
 
I think it is a good idea to take a look at the patch again and to consider using it as a baseground for the Java EE 5 support.

* Jesper Steen Moller
Reading the minutes again (and in the light of the discussions a few weeks back), I noted a slight unease at the prospect of modifying/extending/changing/API'ing the EMF2XML framework. I think this is understandable, since it is mostly unchartered land to many, but it doesn't have to be like that: The framework is very important to making tool support truly good, and with a bit of unit testing, documentation and improved support for some desirable constructs, the unease should go away.

I'm referring to bug reports on improving XML namespace support [1], improving consistency in using attributes vs. elements for some object types [2], improving the support for serializing comments [3]. I'm curently working on a unit test suite for the translator framwork. I'd like to hear the committers if work on these issues will be accepted. I'm using the EMF2XML framework for Mule IDE, hence the interest.

Or, view it the other way around: Current XML Deployment Descriptor support is not going away. Java EE 5 will continue to use XML deployment descriptors for a while, with or without Annotations (there are still things which can only be done by XML DD's). Who knows how this will change in the future. In this light, why not pick up the Java EE 5 XML DD support offered and then go from there, seeing as there is no current alternative to the EMF2XML framework. 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=160567
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=160569
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=164246