[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [wtp-dev] Flexible Project Structure Concepts Document
|
Thank Tim,
It was very clear answer.
I was confused about Target Server and Add/Remove project. I thought
changing Target Server is just another way of Add/Remove a project.
Your answer makes it very clear now it is not. And, now the whole
thing make a lot more sense. :-D
Now that you mentioned "build time statement", I got another question.
So, there is two facdes that a "server" is representing. First, it
hold build time information (JRE/Rutime libs etc). Second, it
represent a connection to a specific server (deploy the project to a
specific server, starting and stopping it etc).
The build time information is part of the project to me. (e.g., your
code might depends on Java2 5.0 feature; or, require J2EE 1.4.) We
assume a build time enviorment as we code the project.
We might change the enviorment as the project evolves. But, it has a
different lifecycle than switching to a different server as we test.
I am thinking that maybe they shouldn't be put together? What does
other people think about it?
Thomas Yip
(P.S. My first mail doesn't seem to go thru. Sorry if anyone receive a
duplicate)
On Mon, 7 Feb 2005 17:40:09 -0500, Timothy Deboer <deboer@xxxxxxxxxx> wrote:
>
> Hi Thomas,
>
> 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.
>
> Thanks,
> 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 03:40 PM
>
> Please respond to
> wtp-dev
>
>
> To wtp-dev@xxxxxxxxxxx
>
> cc
>
> Subject Re: [wtp-dev] Flexible Project Structure Concepts Document
>
>
>
>
>
>
> The deployment or removal of an application will be handled by the Server
> Tools Team led by Tim de Boer, who would be able to answer this question
> better.
>
> Tim -- what are your comments on Thomas's question?
>
>
>
> -------------------------------------------------------------------------
> 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 3:36 PM
> To: wtp-dev@xxxxxxxxxxx
> cc:
> From: Thomas Y <tyip.os@xxxxxxxxx>
> Subject: Re: [wtp-dev] Flexible Project Structure Concepts Document
>
>
>
> Hi Michael,
>
> 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
> is switched?
>
> 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
> project.
>
>
>
> Thomas Yip
>
>
> 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
>
>