Community
Participate
Working Groups
Hello, As you may remember, about two months ago, we suggested to implement support for Java EE 5 projects in WTP. Bug 149007 was created to track the request. Since that time we have gained better in-depth knowledge of the WTP codebase. We saw that the changes needed are much bigger than we have expected at the beginning. Because the changes are quite significant for maintenance release, this led us to the decision to give up the contribution for the R1.5.x maintenance codeline, but work only for the R2.0 development codeline. What we have now is modifications of the WTP plugin that add support for Java EE 5 project. The support is not still full, but it is on a stage already working and useful. Features added by the patch follow: * New version constants for Java EE 5. Version conversion tools are also updated. * New facet version for Java EE 5 projects: web 2.5, ejb 3.0, ear 5, etc. * New Project wizards are updated to allow creation of Java EE 5 projects. * Java EE 5 projects are created with deployment descriptors xml files that refer to the new Java EE 5 xml schemas for validation. * New icons (showing the newer version) for the deployment descriptors node in the j2ee navigator view. * The Xdoclet is disabled for EJB 3.0 projects. This is because Java 5 annotations are used. * Import and Export for Java EE 5 projects. Known limitation: * Appclient 5 projects are not yet supported. * Web and Ejb projects still create web.xml and ejb-jar.xml although this is not required. However this does not conflict with the Java EE 5 specification. * The model is not updated to recognize metadata annotations in the source code. As in J2EE 1.4 project the model only recognizes the project elements in the deployment descriptor. However, this does not affect the correct deployment of projects that use metadata annotations. * The children of deployment descriptor node for EJB 3.0 are removed. This is to avoid frustration for the user who annotates a bean and does not see it appearing under the deployment descriptor node in the j2ee navigator view. * The Java EE 5 has basic metadata annotations support provided by JDT tools (without additional WTP features as wizards, code-completion, etc.). We have tested the implementation against our SAP-specific runtime target - the j2ee application server in the SAP NetWeaver platform. We have not the opportunity to test against other Java EE 5 runtime targets, because there are not any implemented yet. We have also run j2ee automatic tests against our implementation. We also updated the tests where appropriate to test Java EE 5 functionality. Patch will be provided as well. We think that our changes are good base for adding support for Java EE 5 projects in WTP 2.0. Moreover, they touch some important aspects of the WTP 2.0 Plan [1]: * investigate: import a JEE5 project (help wanted) * investigate: export/publish a JEE5 project (help wanted) * validate a JEE5 project (help wanted) [1] http://wiki.eclipse.org/index.php?title=Web_Tools_Requirements_2.0#J2EE_Standard_Tools
Created attachment 50054 [details] implementation patch This are all changes we have made to achieve the changes in the description of the bug. The following plugins are affected: wst/components/common/plugins/org.eclipse.wst.common.emf/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee.core/ jst/components/ws/plugins/org.eclipse.jst.ws/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee.navigator.ui/ jst/components/ejb/plugins/org.eclipse.jst.ejb.ui/ jst/components/ejb/plugins/org.eclipse.jst.j2ee.ejb.annotations.xdoclet/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee.ejb/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee.ui/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee.web/ jst/components/j2ee/plugins/org.eclipse.jst.j2ee/
Created attachment 50055 [details] icons There are new icons added in the 'implementation patch'. For some reason after applying the patch the icons get corrupted. They have to be replaced with the icons from this zip file.
Created attachment 50059 [details] test data This zip contains new content for the TestData directory of the org.eclipse.jst.j2ee.tests plugin. These Java EE 5 project to be imported for testing. The test cases does this automatically, so no changes in their source code is needed.
Regarding: "We have not the opportunity to test against other Java EE 5 runtime targets, because there are not any implemented yet." I wanted to informed that the GlassFish Java EE 5 application is a released server ready for development and deployment. (https://glassfish.dev.java.net/) It has an Eclipse plugin (see https://glassfishplugins.dev.java.net/) so that initial testing can be done to see how this behaves against a fully functional and spec compliant Java EE 5 server. Of course bugs can be filed on https://glassfishplugins.dev.java.net/ so that we can make it work. Regarding Java EE 5 complete support in Eclipse WTP, what is the story for Web Services? See https://bugs.eclipse.org/bugs/show_bug.cgi?id=133205 that applies also for Java EE 5 I guess. Thanks.
(In reply to comment #4) > Regarding: > "We have not the opportunity to test against other Java EE 5 runtime targets, > because there are not any implemented yet." I think he meant noone have written a Java EE 5 WTP runtime target yet, right ? Or is it "just" a matter of having another JEE5 compliant server to deploy against ?
(In reply to comment #5) > (In reply to comment #4) > > Regarding: > > "We have not the opportunity to test against other Java EE 5 runtime targets, > > because there are not any implemented yet." > > I think he meant noone have written a Java EE 5 WTP runtime target yet, right ? > > Or is it "just" a matter of having another JEE5 compliant server to deploy > against ? > Yes, exactly. Thank you for the clarification Max. I meant "WTP runtime target" - the one you choose in the project creation wizard. All WTP runtime targets of Tomcat, JBoss, etc. that come with WTP allow creation of projects up to J2EE 1.4 and does not include the new versions of Java EE 5. These WTP runtime targets has to be updated, not the Java EE 5 compliant application servers. (In reply to comment #4) > Regarding Java EE 5 complete support in Eclipse WTP, what is the story for Web > Services? This is to be discussed with the WTP team in our future telecons about the planning. The focus at my team in SAP at the moment for this contribution is WEB, EJB and EAR project. Of course, we do not exclude the rest of the Java EE 5 specification.
Looking forward to seeing this in WTP. One thing we should be sure to consider as part of this exercise, is how the WTP 2.0 module framework can be improved such that a future enhancement like this is a new set of extensions, rather updates of hardcoded switch statements, etc. If you have architectural suggestions in this regard based on your experience, please let us know.
Naci asked us to track other EE 5 issues here as well. Server tools framework support for EE 5 should be minor, just a few hours work. I'm not aware that any of the servers supported by our current server adapters support EE 5, but if they do, then I beleive adding support to each one of them would be relatively small as well. Adding any new server adapters for EE 5 servers should be tracked as separate work and will require a larger investment.
Responding to Naci's request to respond to JEE 5 issues here, I do not think there is any direct ones here, that I'm aware of, related to editing or our JSP models, related to these patches. Mostly judging from the list of "effected plugins". There's certainly some JSP improvements we want/need to make, just not related here. But, from an overall architecture and extensibility point of view, I did want to say I agree with Ted ... I would hate to go from one set of hard coded values to another set of hard coded values :) ... So far, I have not have time to look at this code so not sure if that's what is being proposed or not.
(In reply to comment #7 and #9) > Looking forward to seeing this in WTP. One thing we should be sure to consider > as part of this exercise, is how the WTP 2.0 module framework can be improved > such that a future enhancement like this is a new set of extensions, rather > updates of hardcoded switch statements, etc. Note: Only the version numbers have hardcoded switch statements. The other switch in there is (or should be) generated by EMF, with the ecore and genmodels in place. EMF in general is as extensible as it needs to be to support this. There is an extension mechanism for EMF2XML, only it doesn't cover the Root element, which would be required for this, nor does it Using this approach would introduce a great deal of coupling bewteen elements (in order to reuse implementation), breaking encapsulation. Since e.g. the EJB model (from the XML point of view) is mostly unchanged, I think that it would be a wiser choice to organically grow the model, translanslators and validator. > If you have architectural suggestions in this regard based on your experience, > please let us know. Today, the root translator is never looked up in the extension registry. This would be possible, but then the extension registry would need to be able to match on version by some means (reduced XPath expression?). I think the proposed patch is a good way to go. Having that in place frees up energy to move on to the annotation issue...
Kaloyan, Many of these enhancements have been addressed, or have separate defects. Can we close this, and open separate defects?
Yes, I close the bug. The basic Java EE 5 support is already available in the WTP 2.0 stream. All defects and future enhancements will be recorded in separate in new bugs. Thanks, Chuck.
closing
