[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [wtp-dev] Minutes of the JEE 5 Working Group meeting 11/30/2006 | 
Raev, Kaloyan wrote:
Hello,
 
Since there are the minutes are not in the wiki yet, I answer to the 
mail.
 
I want to put a comment on a part of the discussion:
 
# 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:  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 
miletsones left) M5 is before eclipsecon.
 
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.
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.
Just my DKK 0,02 (2 øre).
-Jesper
[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