Re: [wtp-dev] server integration proposals

[Gorkem Ercan <gorkem.ercan@xxxxxxxxx>]

Hi Thomas, 
The generic publishers in the generic server tooling do support
associating with a server and a module type so no problems in there,
but publisher chaining is not part of the generic server publishers
but this is a good idea.
-- 
Gorkem Ercan

On Tue, 15 Mar 2005 11:04:39 -0800, Thomas Yip <tyip@xxxxxxx> wrote:
> 
> 
> I think it is a good idea to move the publisher mechanism up.
> 
> I looked briefly on your generic publisher. In additional to associating
> a publisher with a module, we also want the ability to associate a
> publisher with the server instance. We also want the ability to define
> an order of which publishers are invoked. (let me know if I missed
> feature that already exists. :-)
> 
> The publishing lifecycle consists of a few steps. We might need to
> generate some server specific files. We might also want to invoke an ISV
> publisher plugin. The final step might be the actual distribution.
> 
> There are several ways of doing the actually distribution. Among the
> more popular is file copying and JSR-88. For example, a JSR-88 publisher
> that do the actual distribution is general purpose. If there is a good
> implementation available already, a server adapter developer might not
> want to reinvent it.
> 
> 
> Thomas
> 
> 
> > -----Original Message-----
> > From: wtp-dev-admin@xxxxxxxxxxx [mailto:wtp-dev-admin@xxxxxxxxxxx] On
> > Behalf Of Gorkem Ercan
> > Sent: Tuesday, March 15, 2005 5:57 AM
> > To: wtp-dev@xxxxxxxxxxx
> > Subject: 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
> > >
> > _______________________________________________
> > 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
>