RE: [wtp-dev] WTP facets / Module group membership

["Konstantin Komissarchik" <kosta@xxxxxxx>]

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: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] 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.