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

[Michael Elder <mdelder@xxxxxxxxxx>]

Hi Gorkem,

      We intend to drive the Server tooling API off of the pre-constructed
layout on disk. In situations where the developer is using a remote test
server, we will may drive the Server API off the resources as they exist in
the workspace.

On that topic, are there any consumers of this mailing list that regularly
develop by using a remote test server (opposed to a server running on the
same local development machine)?

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

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



Thursday, January 27, 2005 6: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



Thanks Michael,
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
>
>
>
>
> Michael,
> 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
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
 http://dev.eclipse.org/mailman/listinfo/wtp-dev