Re: [wtp-dev] Flexible Project Structure Concepts Document

[Timothy Deboer <deboer@xxxxxxxxxx>]

Hi Michael,

> We know that Websphere can run from fragmented
> Enterprise Applications (like WSAD 5.x and RAD 6.0), but more input
from
> the server team would be helpful here to know what we will need to
do.

The quick answer is "it depends".
:) It is true that WebSphere Application Server can run with an expanded
(unzipped) module structure, with Web or EJB modules that are not physically
contained within the EAR file, and even with utility JARs that are unzipped
and outside of the Web module or EAR that they are "contained"
in. However, this is all largely due to the fact that the Rational tools
team and WebSphere server team have strong ties (note our email signatures
:) ) and we can get features supported in the server that will help developers.
These are definitely not standard J2EE application server features.

Supporting running modules in unzipped
form is fairly straightforward and I would expect that most or all servers
support this feature. They had better, or else there is no point discussing
the ability to run directly out of the workspace. :) Having the Web &
EJB modules outside of the EAR is less standard, and I wouldn't expect
many servers to support this without influence from us. I know of no other
reason to support expanded utility jars outside of the module/EAR, so I
would not expect to find this support in any other server.

As I've discussed with other members
of your team, the more of these features we support to help development,
the less likely it is that a given server supports it. We need to support
most or all of these features to provide a good development environment,
so it's more a question of how we put this into the API and which server
types will be able to run out of the workspace, or be able to pull the
modules back together during publishing to an external server. We'll need
to include Gorkem in this discussion, because the more complex module structures
may make it harder to support publishing via Ant or other methods in the
generic server support.

ttyl,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503  (tieline 969)
deboer@xxxxxxxxxx

Michael Elder <mdelder@xxxxxxxxxx>
Sent by: wtp-dev-admin@xxxxxxxxxxx

02/07/2005 07:00 PM

Please respond to
wtp-dev

To	wtp-dev@xxxxxxxxxxx
cc
Subject	Re: [wtp-dev] Flexible Project Structure Concepts Document

Hi Gorkem,

      To answer your questions:

(1)  Does deployable module output for a module include its dependent
modules? Or to pack and deploy the module, one has to follow its'
dependencies?
The answer is that it depends. For our M3 deliverable, we are focused on
supporting more flexible Web projects, and expect that web library modules
will be archived and pulled into the WEB-INF/lib directory for deployment.
Enterprise Applications will (hopefully) not need to have their dependent
modules pulled in. We know that Websphere can run from fragmented
Enterprise Applications (like WSAD 5.x and RAD 6.0), but more input from
the server team would be helpful here to know what we will need to do.
The
design of the deployment builder is very flexible because of our heavy
use
of "modular/encapsulated" WTP Operations, and it could be that
the decision
of whether to copy in dependents for deployment would be determined by
the
server. Any comments or suggestions on this topic are more than welcome.

(2) If a module depends on two modules in two separate projects and
one of the projects have compile errors, how will the builder behave?
Is it going to be possible to warn user since no dependency check is
performed?

Across projects, we will still have some dependency checking because we
can
scope the classpaths on a per project basis. So if a module has a class
which uses another class in one of its dependents, compile errors will
show
up and carry through. Currently each individual deployable operation is
unaware of compile issues. If the Java builder cannot compile classes for
dependents, then our deployable module builder operations will not be able
to consume those class files and errors could occur at runtime. However,
since we're still using the standard Java builder to compile classes, the
user will be able to see any compile error markers in the dependent
module's classes.

We may be able to handle some validation using the validation framework
that could highlight problems with the user's dependent modules. At a
minimum, we'll probably have to add some validation for paths in the
metamodel that are invalid or for dependent modules that are unresolveable.


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

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



Monday, February 07, 2005 5:36 PM
To: wtp-dev@xxxxxxxxxxx
cc:
From: Gorkem Ercan <gorkem.ercan@xxxxxxxxx>
Subject: Re: [wtp-dev] Flexible Project Structure Concepts Document



Hi Micheal,
I have a couple of questions regarding the builder behaviour with the
dependent modules.
(1) Does deployable module output for a module include its dependent
modules? Or to pack and deploy the module one has to follow its'
dependencies.
(2) If a module depends on two modules in two separate projects and
one of the projects have compile errors, how will the builder behave?
Is it going to be possible to warn user since no dependency check is
performed?

Over all this feels like a good solution, The deployable module
builder and having a ready deployable module output is a great idea. I
am looking forward to it. please let me know If I can be of any help.
--
Gorkem Ercan

On Fri, 4 Feb 2005 18:10:38 -0500, Michael Elder <mdelder@xxxxxxxxxx>
wrote:
>
> Extended Team:
>
>         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 to
> react to the changes caused by this paradigm shift, but we should
be in a
> 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
> iteration.
>
> Thank you for your feedback.
>
>
http://dev.eclipse.org/viewcvs/indexwebtools.cgi/%7Echeckout%7E/jst/components/j2ee/development/design/FlexibleProjectStructureDesignOverview.html
>
> -------------------------------------------------------------------------
> 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
>
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
 http://dev.eclipse.org/mailman/listinfo/wtp-dev

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