Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] server integration proposals

Hello Ted, 
In the server tooling, publish mechanism is a server type related
issue but I have implemented a publisher mechanism for Generic servers
that is similiar to what you describe. In generic servers there is a
publisher extension and Generic server plugin comes with an ant
publisher which can be used for any server. New publishers are
possible to implement.
In generic server no UI for publisher configuration is present,
publishers are associated with a module type in the server definition
file generic server uses. So I would be happy to move some of this
work up to the server tooling.
But I am not sure if a server specific adaptor will make use of a
general purpose publisher. Can you provide a  use case for that?

-- 
Gorkem Ercan

On Mon, 14 Mar 2005 14:28:51 -0800, Ted Bashor <tbashor@xxxxxxx> wrote:
> Hi all,
> 
> Thomas Yip and I from BEA had some good discussions at EclipseCon with Tim DeBoer, Gorkem, and others regarding server integration, and a couple ideas came up that we'd like to see make it into 1.0 if possible.  We understand it's late in the game for significant changes, but we wanted to go ahead and propose these directly to the mailing list to get feedback as soon as possible.  Tim will be better able to comment on stabilization risk, feasibilty, correct my terminology, etc.
> 
> 1)  Use a Builder-like API and UI to provide configurability and extensibility of the publish/deploy process.
> 
>   -  "Publisher" implementations are associated with both project/module type and server type.
>   -  Publishers do not execute within the same lifecyle as the incremental builders.
>   -  WTP will provide at least one publisher implementation which may be usable for multiple server types.
>   -  Third parties can implement alternate or additional publish steps for a particular server type
>   -  Users will be able to go to the Project Properties dialog to enable, disable, and configure the various steps in the publish process
>   -  Users can add their own publishers (e.g. execute some ant script before or after the default assembly/deployment operations)
> 
> We probably won't be able to support this for 1.0, but ideally, one would be able to target multiple server types from a single project.  My project could have a common build process, but unique publish process, per server type.
> 
> Another item for the future... would be nice if the same model were adopted for the Export process.  It's quite likely that some publish operations could be factored into "assembly" steps and shared between Export and Publish actions.  (Plus this might provide an interface for persisting some export configuation choices)
> 
> 2)  Update the Servers view to display module state and status
> 
>   -  Servers view would become a tree table displaying the modules registered for deployment to each server
>   -  A problem may be associated with both servers and modules.  E.g.  an error starting the server would cause a problem to be attached to the server.  The problem would be cleared when the user attempts to start the server again.  Likewise, an error publishing a particular module would cause a problem to be attached to the module, which would be cleared before beginning the next attempt to publish the module.
>   -  State and Status of both servers and modules will be displayed in the Servers view.  Need to reach agreement on what "State" and "Status" mean.  My two cents:
> Server "State":  Stopped, Starting..., Started
> Module "State":  Unpublished, Publishing..., Published
> "Status" is the text of the the problem, if any, currently associated with the server or module.
>   -  Module rows in the Servers view will have context menus.  Hopefully, we will be able to support (re)publish operations on individual modules.
> 
> -Ted
> 
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/wtp-dev
>


Back to the top