Using a local dev server (each developer runs their own server locally) and pointing it to one of your working directories that contains an exploded app is nice. The time it takes to deploy changes needs to be short to keep productivity up -- it seems unlikely that a process that involved creating a WAR or EAR archive file and redeploying it would be snappy enough.
We often have an exploded war directory (named web/, typically) that is structured just like a war. Then we have a separate /src directory with the Java sources. Those get compiled (and other .properties files copied) into web/WEB-INF/classes by our build process. This works pretty well. You can edit JSP files and the changes are picked up immediately. And you can run the build to compile the Java sources and then reload the app in the server to pick up those changes. It is important to not have any sources in web/WEB-INF/classes so that you can delete that directory on a rebuild. However, it seems like there is a time in each project where I would like to have the build process do something to the files in web/ before they are deployed (trim extra whitespace from JSPs, assemble help content files, put a build timestamp in some file, etc.). It seems there is always a time where I would prefer to build the war somewhere else so that I don't have "false changes" to the real source files. Some things are better done at build time than runtime, but it is difficult to accommodate such processes if your working mode is to have your dev server pointing directly to your "source" directory for the web stuff (though I still like the war layout, even if you aren't running a server against that dir). I think a decent compromise is to have your build script build an exploded war directory tree in a build output location like build/webapp. Then you point your local dev server to that directory instead of directly at the sources. Make sure the build is fast (at least when there are few changes) and easy to run. I prefer to have one entry point for "building the web app", rather than having a multitude of public build targets for copying JSPs, compiling Java, etc. -- too many targets gets too confusing, you may have picked up someone else's changes from your VCS, and in general I think you can make an Ant script that runs fast enough to do this. There is a risk that people may edit JSPs in build/webapp and get their changes overwritten, or it may simply be nice to support the option of editing JSPs in place to avoid having to run the build for each JSP edit. I haven't tried it, but I suppose you could make the copy-jsp target (that your single-entry-point build-webapp target depends on) in your build to be kind about such changes (fail, or even copy them back if a file in build/webapp is newer?). That's my brain dump on this subject. - edit -> build -> war -> deploy -> test : Too slow! - edit -> build? -> reload? -> test: Good productivity, but limits your webapp build options - edit -> build -> reload? -> test: Decent productivity, flexible -Max On Mon, 2004-11-29 at 12:41 -0500, Dahnke, Eric (Company IT) wrote: > Hello List Members, > > Whether to layout a project within version control as a WAR based layout > (images/ pages/ tiles/ WEB-INF/ WEB-INF/src) or as a sun J2SE blueprint > layout (build/ conf/ src/ lib/ webapp/ docs/ test/ etc. > http://java.sun.com/blueprints/code/projectconventions.html) is an issue > that has long plagued me as a developer and more so as a manager who > oversees java developers as well as jsp/dhtml client side personnel. > > I've only ever found one or two good threads on the subject, and most > (but not all) Java developers I've worked with have favored the J2SE > approach. The _HUGE_ downside of this approach is that for a client side > jsp or html coder to work, they have to use at minimum Ant and often > times have a full IDE installed, so they can WAR the application, deploy > it, reload the app server, just to see if changing some column size > gives them the output they were hoping for. > > Assume a standard web application, and the display tier technologies are > html / jsp / css (not xslt and xml - as that could be a solution - but > not for rich client side web functionality IMO) > > > Has anyone experienced a development process or project layout that can > accommodate the J2SE best practices and keep client-side developers away > from the drudgery of compile_jar_war_deploy_reload just to see a simple > js, css, or html change? I can think of a hybrid approach as well the > idea of creating multiple vcs projects for the different team members, > but neither of those ideas excite me. > > > Thanks, Eric > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender does > not waive confidentiality or privilege, and use is prohibited. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
