I have a little knowledge with WTP and how you relate to it.

I had a quick look at WTP since i never played with it before and had to realize by myself (even though i have been told) that you cannot deploy an exploded EAR with exploded WARs inside. That is just too bad :(

A 'basic' Seam application using EJB3 will have 3 projects most of the time. An EAR, a JAR, a WAR but one could want more than a single JAR or single WAR.

I will have a talk with Max and see what we can do.

Let's have lunch today about it ;)

The deployment issue is something that Stryker should be able to shed a light on. I was hoping he could make that happen somehow ;) Rob?

Additional jar's I can understand, but when is additional WAR's interesting/relevant ?

I'll also have to give it some thought on how the app generation templates and UI can be adjusted to generated into this more scalable structure. e.g. right now it assumes one root where as here we will have three roots.

Right now default behavior for running the WTP projects on a server is to package them up. Having the option to deploy exploded is a feature I'll try to work in.

..hopefully something that will work toegether with marshall's packaging "thingy" and then optimally can "copy-on-save" so edits will be instant for e.g. JSF pages.

Optimally it would be cool to get a deployment to point directly to the web src tree in the project, but i don't think that is easily doable ? Andy talked about being able to specify what URL's a jboss installation should look at?

You can easily add a new directory to scan for deployment on JBoss but the packaging is not correct on WTP (You can't have a War inside a Ear).

A copy-on-save would do the magic.

Having exploded archived is a *Very important* feature it lets you fix your JSF pages without having to redeploy.

ok - but how do you (easily) add a new directory for scan for deployment ?

It's in jboss-service.xml it's the URLDeploymentScanner mbean

<!-- URLs are comma separated and resolve relative to the server home URL
 unless the given path is absolute. If the URL ends in "/" it is
 considered a collection and scanned, otherwise it is simply deployed;
 this follows RFC2518 convention and allows discrimination between
 collections and directories that are simply unpacked archives.

 URLs may be local (file:) or remote (http:). Scanning is supported
 for remote URLs but unpacked deployment units are not.

 Example URLs:
 deploy/
 scans ${jboss.server.url}/deploy/, which is local or remote
 depending on the URL used to boot the server
 ${jboss.server.home}/deploy/
 scans ${jboss.server.home}/deploy, which is always local
 file:/var/opt/myapp.ear
 deploy myapp.ear from a local location
 file:/var/opt/apps/
 scans the specified directory
 http://www.test.com/netboot/myapp.ear
 deploys myapp.ear from a remote location
 http://www.test.com/netboot/apps/
 scans the specified WebDAV location
 -->
 <attribute name="URLs">
 deploy/
 </attribute>

I now have the booking app as WTP projects with configuration for JBoss AS. (In our current examples we do Ant filtering to configure the examples for one app server or the other (or Tomcat)

I will document the elements that need customization and how names are related (for example you build the JNDI name from the EAR Name followed by some stuff)

If you need my Eclipse Workspace for this example, let me know we will try to find a way to send the 13MB of compressed files...

13 megs? insane ;)

just zip it and attach it to the jira case.

The limit is 10Mb ;)

You can FTP it from my machine Max.

For others, if you are interested let me know and we'll find a way

well, people like to change their JSF's today while they are in some structure that J2EE can deploy...can't you just tell it to monitor some rootdirectory ?