Re: [wtp-dev] Current Status of Flexible Project Design: Request for Fee

[Gorkem Ercan <gorkem.ercan@xxxxxxxxx>]

Thanks Micheal, 
This is really helpful. I am still curious on how this structure
relate to the Module structure in the server tooling but I am guessing
that it is early for these details.
Gorkem Ercan


On Wed, 26 Jan 2005 16:39:18 -0500, Michael Elder <mdelder@xxxxxxxxxx> wrote:
>  
>   
> Hi Gorkem, 
>   
>    To clarify the constraint in (2), the resources referenced by a module
> will not be allowed to span multiple projects. However, in our metamodel,
> modules have the concept of dependent modules. These dependent modules are
> allowed to span multiple projects (as it is not a formal containment
> relationship). In the case of an EAR, the "modules" relationship will
> reference the uris of the WorkbenchModules that compose the deployable
> WorkbenchApplication. Other modules will have their dependencies enumerated
> (such as a webapp which specifies web lib modules). These modules are
> referenced by a special "module:" URI, so that we can refer to a module,
> even if that module is not contained in the same project. 
>   
> Here is a screen shot of our evolving model: 
>   
> The note "Because ..." refers to the fact that all of the resources
> referenced by this model file must be 
> contained in this project. 
>   
>  
>   
>   
> Does that answer your question? 
>   
> ------------------------------------------------------------------------- 
> Kind Regards, 
>   
> Michael D. Elder 
> Rational Studio / J2EE Tools Development      
> IBM RTP Lab 
> Ext: (919) 543-8356 
> T/L: 441-8356 
> mdelder@xxxxxxxxxx 
>   
>   
>   
> Wednesday, January 26, 2005 4:06 PM 
> To: wtp-dev@xxxxxxxxxxx 
> cc: 
> From: Gorkem Ercan <gorkem.ercan@xxxxxxxxx> 
> Subject: Re: [wtp-dev] Current Status of Flexible Project Design: Request
> for Feedback
>  
>   
>   
>   
> Micheal, 
> I have a few questions concerning the EAR modules. I imagine that the 
> best way to work within this context is to have separate projects for 
> each module. (I guess this will be the best practice) but according to 
> the item 2, a module will not be able to span more than one project, 
> so if I were to have an ear module to include two modules, would I 
> need to put them in in a single project and compromise on dependency 
> checking? Will the EAR modules (modules that may include other modules 
> in general) be handled in a special way? 
> Regards, 
> Gorkem Ercan 
>   
>   
> On Tue, 25 Jan 2005 16:19:32 -0500, Michael Elder <mdelder@xxxxxxxxxx>
> 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 
> > 
>   
>   
> -- 
> Gorkem Ercan 
> _______________________________________________ 
> wtp-dev mailing list 
> wtp-dev@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/wtp-dev 


-- 
Gorkem Ercan