A (server) runtime target is the compile
time target for a particular project. When you target a project to a particular
runtime, it will typically change the classpath, and may change validation
or other settings on the project. It only takes as long as a rebuild.
The limitation that is outlined in the
document is that there is only one runtime target per project, whereas
the project may contain multiple applications or modules. The reason for
this is simple - most Eclipse settings, like classpath, can only be defined
at the project level. So if you have one module module per project, you
have ultimate flexibility of targetting each module to a different runtime.
When you put multiple modules in the same project, they will be targetted
the same, regardless of whether they are going to be deployed to different
servers. In my experience, this is not a huge restriction since putting
the modules in the same project typically means that they have some affinity
and will likely be deployed together.
This targetting is a build time statement,
and ultimately does not affect deployment. Switching the target does not
deploy the project to the new runtime or undeploy it in any way. Although
we may warn you or provide some other mechanism for situations where you
compile against one server and run on another, this may often make sense
or not be an issue. To add or remove a module from a server, you can (among
other ways) go to the Servers view, right click on a server, and choose
Add/Remove Projects (note - menu item will be renamed now that there may
be multiple modules per project). Moving modules to the right deploys them
to the server, moving them to the left undeploys them.
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
Michael Elder <mdelder@xxxxxxxxxx> Sent by: wtp-dev-admin@xxxxxxxxxxx
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
Monday, February 07, 2005 3:36 PM
From: Thomas Y <tyip.os@xxxxxxxxx>
Subject: Re: [wtp-dev] Flexible Project Structure Concepts Document
Well written document! :-) Thank for the hard work.
I have question about server target.
In the doc, it says: "(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."
Does a module being undeployed from the original server target when it
If it does, undeployment following a full deployment can be very
expensive and taking tens of minutes with large apps.
If it doesn't, it seems that there is no way in web tools to undeploy a
On Fri, 4 Feb 2005 18:10:38 -0500, Michael Elder <mdelder@xxxxxxxxxx>
> Extended Team:
> The following document provides an overview
of the Flexible
> Support. We are targeting the completion of the first draft of the
> Project API for the M3 milestone. Most teams will not have enough
> 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
> update our design as necessary.
> A more formal API and migration document will
be delivered at the
> of the M3 cycle in preparation for teams to migrate during the M4
> Thank you for your feedback.
> Kind Regards,
> Michael D. Elder
> Rational Studio / J2EE Tools Development
> IBM RTP Lab
> Ext: (919) 543-8356
> T/L: 441-8356
> wtp-dev mailing list
wtp-dev mailing list
wtp-dev mailing list