WTP style "deployment" (WAS: Re: [jbosstools-dev] https://bugs.eclipse.org/bugs/show_bug.cgi?id=241335)

John Graham jgraham at redhat.com
Thu Oct 30 10:25:24 EDT 2008


Ok -- so I'll take this as an opportunity to rant. ;)

But, before I do, just so I don't wrongly upset people, please note:

* I am not criticizing the decision to use WTP deployment: back when the
decision was made, it was completely reasonable to assume the WTP would
create and maintain a first-class deployment solution.

* I am not criticizing the work we've done to enhance and build on WTP:
we've done a fine job of that, and have even worked around some WTP
limitations in the process.

* I am not criticizing the work recently done for ESB deployment. Denny
and Rob have built on the WTP framework in the expected manner, and it
works the way WTP would have it.

* I am not suggesting short term changes, but rather that we should
reconsider this vital area for future releases (not too far in the
future, I hope... ;) )

The WTP deployment framework suffers from a number of architecture,
implementation, and process limitations. Based on good faith
interactions with Eclipse WTP (mostly Rob, but sometimes me), the WTP
team seems in no way interested in addressing these issues. In short:

* The WTP Servers view, and hence deployment, assumes that you have
control over the target server. You start and stop the server directly
from this view. If the server is already running, then the view has no
way of finding this out. This is ridiculous: imagine trying to do team
development on a shared server (say with a number of other applications
already installed). How's that supposed to work? Everyone starts/stops
the server at their own whim according the dictates of the tools?
Ridiculous.

* You map one project--one server, and the project structure has to
mirror the deployed archive structure. Too low level! I want the freedom
to have resources wherever I want in my project (and perhaps even
referenced projects), and I want a separate way of determining the
deployed archive contents. I don't want to bind one project to one
server: I want to deploy archives to a set of servers from the same
project. 

* Even though there's a tight mapping between one project--one server, I
still can see the contents deployed on the server. Sure I can see the
"module" name and it's current synch status, but I can't see what is in
the server. If I want to compare a file on the server with something in
my workspace, I'm out of Eclipse to do so.

* The archives and projects are not reusable. Because they are tied
directly to local environment details (server connections and
classpath), it is difficult (yes, not impossible, but far more difficult
than it has to be) to share and store these projects (say in version
control, where I can easily repro the environment for any project
version).

The alternative? Have a deployment descriptor (think something like
"build.properties" for you plug-in developers out there) that specifies
the contents for a specific deployment archive. Tools that let you build
local versions of the specified archive and optionally deploy to a given
set of target servers. A server view that can ping ports to first
determine if the server is running... A server view that can show me
what is on the server (not just my archive), and let me interact with
those resources in a typical manner (that is, the server deployment
space acts like a virtual file system).

</rant>

-- John

On Thu, 2008-10-30 at 11:15 +0100, Max Rydahl Andersen wrote:
> Hi,
> 
> I just bumped into subject and it looks like both Eclipse WTP and possibly  
> our AS adapter is seriously broken on Ganymede when
> it comes to JEE 5 EAR deployments ;(
> 
> jboss-seam.jar only gets deployed if I force a full publish and even then  
> it does not seem the lib folder that is being talked about in the id
> is being created in the deployed archive.
> 
> Any info about it would be appreciated.
> 




More information about the jbosstools-dev mailing list