[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-dev] Why Do We Need the Preference to Enable MultipleModules per Project?
|
Robert, you hit the nail on the head.
There are two parts to the "flexible project" initiative that are often talked about as one: flexible folder structure for a module, and multiple modules per project.
The flexible folder structure part is vital for supporting a broad range of customer directory layouts.
Multiple modules per project is an attractive idea from a source control/team development perspective, but its supporters might not be fully appreciating the classpath issue. Modeling the J2EE runtime classloader heirarchy accurately is a very important part of a good J2EE development tool. I don't want to have my source editor offer auto-import and statement completion to types that are not going to be available at runtime. That would seem like a pretty broken tool. I think it's a strech to even call it an "Advanced" option. Will you really choose not to adopt WTP if your EAR must be composed of multiple projects instead of one?
While flexible folder support is something we legitimately can and should try to do well in WTP 1.0 and eventually push down to platform in some form, unfortunately the ability to group multiple modules for team development is a problem that can only be well solved in coordination with the platform/JDT. Hopefully this issue is high on their planning for 3.2.
-Ted
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On
Behalf Of Robert Sanheim
Sent: Thursday, July 07, 2005 9:51 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Why Do We Need the Preference to Enable
MultipleModules per Project?
My 2 cents as a long time user and follower of WTP:
- flexible projects increase complexity a lot without much benefit
- from reading the newsgroups the vast majority of feedback has been
negative, particularly when flexible projects became the default for
whatever integration build it was. It made cvs integration/checkouts
a nightmare
- the true "flexibility" that users need is the ability to define
their own folder structure so they can have a typical ant style layout
of /web, /src, /lib, etc or whatever their team dictates. Changing
the folder structure should not break cvs checkouts, as I've seen
happen with my own web projects when I try to do something as simple
as rename JavaSource to src and modify .wtpmodules.
- there have been numerous posts and requests for folder structure
flexibility in the newsgroup, and related posts about the pain of
hacking .wtpmodules as a work around. I've seen few posts abouts
flexible projects since its become an option disabled by default. See
the bug for the folder structure issue I opened:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981.
It seems the issue of allowing users to setup their own folder
structure (on a per-project and/or global level) should at least be
considered along side flexible projects, if not prioritized higher.
Thoughts?
- Rob Sanheim
--------------------
http://www.robsanheim.com
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev