I'm a big believer in simplicity. To that end, the way we work here at my behest, at least during development, is that applications are simply zipped up when they need to be moved somewhere and deployed in exploded form. All developers have Tomcat on their desktop, set up identically, so they just unzip the archive into their webapps directory (when not pulling from source control) and off they go. The same goes for migrating a build up to a test server... Just copy, unzip and off you go. This makes changes very easy. Page developers have the entire thing on their desktop, but they can "hot-swap" JSP's, CSS and whatever else without recompiling or WARing anything. Generallys-speaking, everyone is pulling the project out of source control in the morning anyway, so there's not really much passing around of archives, but that's the way we put it on the test server. No tools required (I generally dislike IDEs), no extra knowledge needed, just an easy time of it :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, November 29, 2004 1:08 pm, Dahnke, Eric (Company IT) said: > > Damn, that's not bad is it. I had thought of variations of that, but > hadn't considered ant. Those types of ant tasks would be fast too > wouldn't they. > > Having client siders use ant is not a show stopper (they use it now to > reload after struts-conf and tiles-defs changes they make). Thanks > > > > >> Have you considered deploying exploded versions of your WAR >> file in the development environment? The client side coders >> could then copy their deltas directly into the application >> without having to build and redeploy it. The means of copying >> the files could be automated by making the exploded app the >> target directory within their development tool (e.g. >> Dreamweaver) or by providing Ant tasks such as copy-jsp, >> copy-css, copy-images etc. >> >> If exposing client side coders to Ant is a showstopper then >> this approach won't help but Ant really isn't much of an >> overhead and it shouldn't ever *require* an IDE as best >> practice dictates that your Ant script should always be >> runnable _independently_ of any IDE. >> >> Nothing dramatic in this approach - just a quick and simple >> way of balancing different needs/responsibilities whilst >> maintaining a consistent approach to build/deployment tasks. >> >> Colm >> >> >> -----Original Message----- >> From: Dahnke, Eric (Company IT) >> [mailto:[EMAIL PROTECTED] >> Sent: 29 November 2004 17:41 >> To: Struts Users Mailing List >> Subject: WAR based project layout vs Sun J2SE blueprint layout >> >> >> >> 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] >> -------------------------------------------------------- >> >> If you are not an intended recipient of this e-mail, please >> notify the sender, delete it and do not read, act upon, >> print, disclose, copy, retain or redistribute it. Click here >> for important additional terms relating to this e-mail. > http://www.ml.com/email_terms/ > -------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -------------------------------------------------------- > > 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]
