Skip to main content

[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




Back to the top