You are correct in the assumption that
modules contained inside Ear's should be treated the same as any dependent
module. At first we did model an "ApplicationModule", but
dropped it since we handle these "modules"
essentially the same.
Your first use case (Ear, web, and ejb
all in same project). There would be three WorkbenchModule instances
defining the source location of each. The Ear module would have 2
dependent modules, and the web project could have 1 dependent(ejb) if Ref's
The second case, would have one Workbench
module in the EAR project defined, and two dependent modules, using the
"handle" to reference the other workbench modules defined in
a seperate project.
As for the concrete api, we wanted to
introduce an extendable module type framework/pattern. The ArtifactEdit
pattern explains how this helper class(An Adapter), when used in a module
context, can provide the api necessary for type specific function (getWebApp(),
We will continue to update this paper
as more api is flushed out. Thanks for reviewing...
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Phone: 919-254-1848 (T/L: 444)
Naci Dai <naci.dai@xxxxxxxxxxxxx> Sent by: wtp-dev-admin@xxxxxxxxxxx
This is great progress. Your team have presented a simple to understand
model, which is an achievement on it own. Here are some questions/comments.
- The concept of a DependentModule
is presented as a mechanism where a module such as a WebApp will reference
other modules, such as an ordinary Java library (i.e. struts.jar)
that will typically end up in the web-inf/lib after a deployable structure
is build. I also presume that this is the same mechanism you have
envisioned to assemble an EnterpriseApplication (ear). Is it
so? I have the impression that ears are somehow treated differently
than other modules in WTP. This could be an incorrect statement but
can you elaborate a bit on the following use cases:
-Ear and web and an ejb module are all inside
a same project
-Ear is a separate project and web/ejb are
in the same project (your model allows for inter-project module dependency)
-They are all in separate project.
The reason I am concerned here is that I do not think an EAR is that special
to have its own separate way of being handled.
- A minor point but the XML example you provide have the same Tag to define
a module and its type
<wb-module deploy-name="Foo.war" >
It is preferable and better style to have a different tag for the module
type (i.e. <wb-module-type id="jst.web" />
- When publish the API for concrete subclasses of the WorkbenchModules
(i.e EjbModule / WebModule) we will be in a better position to comment
on the APIs. However, we should be able to query a WorkbenchModule
for its source folders/output folders. To be more precise, the modules
which may have source folders, such as an EjbModule/WebModule. I
suspect the builders use such API. We will definitely need it for
At 01:10 AM 2/5/2005, Michael Elder wrote:
The following document provides an overview
of the Flexible Project
Support. We are targeting the completion of the first draft of the Flexible
Project API for the M3 milestone. Most teams will not have enough time
react to the changes caused by this paradigm shift, but we should be in
position to bring them onto the new structure through the M4 cycle and
update our design as necessary.
A more formal API and migration document will be delivered
at the end
of the M3 cycle in preparation for teams to migrate during the M4