Skip to main content

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

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.


> -----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>
> > Hi all,
> >
> > Thomas Yip and I from BEA had some good discussions at EclipseCon
> Tim DeBoer, Gorkem, and others regarding server integration, and a
> 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
> 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
> 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
> >   -  Users can add their own publishers (e.g. execute some ant
> 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.
> project could have a common build process, but unique publish process,
> 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.
> an error starting the server would cause a problem to be attached to
> server.  The problem would be cleared when the user attempts to start
> 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
> the Servers view.  Need to reach agreement on what "State" and
> 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
> 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
> modules.
> >
> > -Ted
> >
> > _______________________________________________
> > wtp-dev mailing list
> > wtp-dev@xxxxxxxxxxx
> >
> >
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx

Back to the top