Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Flexible Project Structure Concepts Document


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


Back to the top