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]
