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