Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Current Status of Flexible Project Design: Request for Feedback

Michel,

Thanks for the status update. I think we are on the right track, but I would like to reinforce some of the comments that were made:

1)  A module split into multiple projects is out of scope. EXCEPT
.EAR modules can be easily split into multiple projects and should be supported.

2) Extensive use of builders to create artifacts and deployment setups is architecturally clean. EXCEPT Builders should be configurable to be turned off. Extensive validation/compilation/generation can slow down the tools and IDE and ultimately can make the whole envirobment very frustrating to use. The reverse side of the coin for a builder is that it is automatic, and therefore, magic to the developer. Also, interactions between builders can get exponentially complex to manage.
        Mu suggested best parctices
                -Use them but do not make them compulsory.
-Expose them to the developer so that they can disable/change them.


Finally can you elaborate a bit more one why "each moule will have its source folder(s)". I was not clear on this constraint. If this is only a packaging issue. There are maybe other alternatives to managing it.





At 11:19 PM 1/25/2005, Michael Elder wrote:

Extended Team and Consumers:

      The purpose of this email is to give you an update regarding the
state of the flexible project design and implementation. After much
discussion of a feasible solution to the problem of arbitrary structures
for modules and multiple modules per project, we have found the need to add
a few constraints to the problem we are trying to solve. We would like
feedback on your opinions concerning these constraints:

(1) The solution will not check dependencies for modules that are contained
in the same project. To get the full benefits of inter-module dependency
checking, modules must be separated into different projects. We do not have
the necessary flexibility in constructing and scoping classpaths on a level
more granular than the project level, which would be needed to support this
functionality.

(2) The solution will not allow a single module to span more than one
project. Within that project, we will have fairly broad flexibility to
specify which resources map to which modules. Each module within a project
must have its own source folder, but a module may contain more than one
source folder. It would be discouraged or completely disallowed for a
single source folder to be contained by more than one module.

(3) The solution will not allow more than one server target per module (and
really per-project) at a time. The ability to switch this server target
(via some action or property setting) will continue to be possible. Users
that need the capability to develop for multiple server targets will need
to manually switch and test as necessary.

(4) Each module in a project will have its own output folder structure
automatically constructed for it. The output structure will match the
J2EE-spec output structure required for the module type (for J2EE modules).
A new builder will handle this responsibility and work cooperatively with
the Java builder to construct a deployable, on-disk representation of the
module structure. The necessity for this on-disk structure to match a
J2EE-compliant layout is motivated by the requirement to have in-workbench
testing, so that users will not have to deal with a deployer actually
constructing a deployable module and shipping it off to a server to test
their code. This approach is consistent with existing Ant-based approaches
and Application Servers which can run in a "debug" mode on disk. Our
value-add will be greater automation and integration with the workbench --
particularly for incremental based support. The specialized module builder
would not be necessary if the source was already in the appropriate
J2EE-spec compliant structure. The default creation will still encourage a
single module per project, which conforms to the correct J2EE structure.

(5) Modules will be described using a simple XML format, and each project
will contain one .wtpmodules file that will describe all of the modules for
that project. The level of tooling to help users create these files is yet
to be determined for WTP M4. This would be a great area for other
interested developers to suggest and provide tooling (e.g. a Wizard or
Editor) to create these files from existing structures.

Many thanks to the patient members of the Eclipse and JDT teams for helping
us work through these problems.



-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx


_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/wtp-dev

Naci Dai,
Managing Director

eteration a.s.
Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 81090
+90 (532) 573 7783 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com
mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx





Back to the top