Rob, The question of allowing multiple modules per project has a long and sordid past. Actually, there was a brief period in time when that was actually sort of supported. The problem is that by allowing it, we were going against the grain of all of Eclipse and had to fight and/or re-implement things instead of seamlessly integrating. Here are two of the problem areas as an example, but there were many other: (1) can only have one classpath per project - want to have separate classpath for each module, (2) can only have one list of builders per project - want to have separate list of builders for each module, (3) want to have module-level preferences - can only have project properties. In the end, it was decided that WTP was not the appropriate level to solve this problem. A series of enhancement requests were opened to Eclipse platform to support interleaved project directories, which would serve the same purpose of allowing user to organize their files physically in any way they choose without messing with Eclipse project model. Some of these requests have been resolved, but there are still many outstanding issues. Regarding your specific question about ejb 3.0 facet, there will be a discussion about this at tomorrow's J2EE Working Group meeting. Are you planning on dialing in? - Konstantin
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Stryker Sent: Wednesday, January 31, 2007 10:44 AM To: General discussion of project-wide or architectural issues. Subject: [wtp-dev] WTP facets / Module group membership I recently commented on an ejb3-related discussion, but I feel the issue I bring up is project-wide and could benefit from wider group discussion. https://bugs.eclipse.org/bugs/show_bug.cgi?id=167101 My comment is included below: 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? _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
