Community
Participate
Working Groups
Using the same facet id, create a seperate definition for the "3.0" would like to do this in seperate plugin... extension point required would point to seperate install delegate class, for example: <!--EJB3--> <project-facet-version facet="jst.ejb" version="3.0"> <action type="install"> <delegate class="org.eclipse.jst.j2ee.ejb.project.facet.Ejb3FacetInstallDelegate"/> <config-factory class="org.eclipse.jst.j2ee.internal.ejb.project.operations.EjbFacetInstallDataModelProvider"/> </action> <constraint> <and> <requires facet="jst.java" version="[1.3"/> <conflicts group="modules"/> </and> </constraint> <group-member id="modules"/> </project-facet-version>
First step is to create a simple Java Utility project like structure, do not create a XML deployment descriptor until we work out problems distinguishing the new namespace version. Validation is one issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=167097
Created attachment 55533 [details] patch to disable validator for ejb 3.0 project
Moving to M5
Hi Chuck, I have tested the build from this location: http://download.eclipse.org/webtools/committers/drops/R2.0/I-I200701110425-200701110425/ Here is my feedback: 1) In the New Ejb Project wizard I can now choose version "3.0" for the EJB Module facet. 2) If I choose version 3.0 the Next button becomes disabled and I cannot go to the "Configure ejb module settings" wizard page. I can only click the Finish button. The ejb project is created successfully. 3) Initially the ejb3 project does not have ejb-jar.xml file. But expanding the META-INF folder and then right-click on the project's node, an ejb-jar.xml is generated. However, the generated xml file contains only the string '<?xml version="1.0" encoding="UTF-8"?>'. This is not a valid ejb-jar.xml file an may cause problems when deploying on the application server. 4) Sometimes after self-generating the ejb-jar.xml file, the IDE hangs and utilizes the CPU to 100% for a long time. I attach a full dump stack taken at this time. 5) In the New EAR Application Project wizard I can now choose version "5.0" for the EAR facet. 6) According to the Java EE 5 specification the correct new version for EAR is "5" and not "5.0". 7) If I choose version 5.0 the Next button becomes disabled and I cannot go to the "J2EE Modules to Add to the EAR" wizard page, where I should select ejb3 modules to add to this EAR project. I can only click on the Finish button. The ear project is created successfully. 8) If I go to the "J2EE Module Dependencies" property page of an ear5 project, there is nothing to choose there - even the ejb3 project that I alraedy have in my workspace. Combining to with 7) there is no easy way for the user to add ejb3 modules to his ear5 project. I would like to refer again bug 157185. There is a patch that provides support for Java EE 5 projects. While we working on the patch we faced the same problems (except hanging the IDE) as described above. The solution for them can be found in the patch. There is comment from David that he does not like the way the solution is provided. But, as far as I can see, you Chuck are going on the same steps as we did. So, I recommend that you take another look at the patch - I am sure there ideas that can help you. Greetings Kaloyan
Created attachment 56824 [details] full thread dump when IDE hangs with 100% cpu
Thanks Kaloyan, We are aware of some of these issues, and will be looking into them. The fact that the model(ejb-jar.xml) is generated is wrong, and we will be tracking down where this is being triggered. The existing model classes should not be used for the new facet version, but many existing api's don't consider facet version before proceeding.
The JBoss Team's question, ejb3 specific: Does the jst.ejb 3.0 facet need to be a member of "modules"? Clearly ejb3 is different enough that it doesn't need it's own project, as it's pojo-based. The wider question (which should, perhaps, be its own bug / discussion?): What is the reason that every member of group "modules" conflicts with group "modules"? Perhaps I dont understand the depth of the API, but what benefit do you get out of declaring each project can only have one module type? So far, the only benefit I've discovered is that it makes the packaging and publishing of WTP projects very standardized, figuring out the parent / child project relationships, and then packaging accordingly. Many users will still insist on doing their packaging in a customized way, refusing to use the standard packaging supplied by wtp and jst generic servers. They may use their own ant script or some other mechanism / plugin. In that case, limiting the number of modules to one per project seems to be highly restrictive with very little benefit. This becomes even more of a problem when other units of functionality require specific facets (like JSF requiring a project with the web facet, which automatically means an ear, ejb, etc project cannot include the jsf functionality.) You'll probably all say there's no reason for an EAR or EJB project to include any JSF-related code, anyway, and you'd be right, but many users are resentful of having to split their application into so many units according to webtools' restrictions. They'd rather structure their projects as they see fit, and sometimes this means creating projects with multiple modules types. So again, what actual benefit is there to restricting on module type?
Created attachment 58292 [details] patch for jst.ejb Hi Chuck, I agree that after you apply this patch, any problems associated with the new facet should be addressed by new bugs. We should close out this bug.
dropped to build
Verified
