[
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
|
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