Ted, Take a squizz at the tutorials I put up on my nested extension page. http://www.keyboardmonkey.com/stats (thinking of putting up a support group page for "blatant traffic generators anonymous" too. You in? :)
Starting off with the war file of everything needed with exception of files needed to run struts. Each file is waiting for them with an underscore on the end so all they have to do is rename it to remove the underscore (when the tutorial specifies) and they're in business. This way I saved files from being seen by the compiler until required. The files are empty with exception of package and import declarations, so they still have to code the body logic. After each milestone there's another war file of everything up to that point. This goes on until the end where there's a running war file at the very end to check against the final running version. As for the tutorial's content, a full version of each source page is available at every step as well as the code supplied on the page itself. Making the milestone war files (six in the tute) were a genuine pain in the ass (that's donkey :), but got it under control with some automated scripts to compile, package and deploy all at once for testing an uploading. I've already had some excellent feedback as to people really getting benefit as to the way the tutorial worked (one even said it was about the best online tutorial they've ever taken). So I think that the effort in creating tutorials in such a manner is beneficial. It does add to the development time however. All that other stuff in the blank.war etc... blank.war was how I first started hacking Struts, so I'm +1 on keeping that system alive. Arron. PS: Any tag extensions planned for the "Short Term Plans"? :) Ted Husted wrote: >Martin Cooper wrote: > >>I'm planning on making some other changes to the Struts build process in the >>near future, and I could certainly roll these in if people think it would be >>desirable. >> > >Here's a different but related issue. > >For the example applications, I'm wondering if we want to adopt a file >system format that allows someone to download and install the WAR, and >have all the source code in place, ready for exploration and tweaking. > >This is the approach I've been taking with my own examples. > >http://husted.com/struts/resources/struts-simple.zip > >http://husted.com/scaffolding/dist/logon.zip > >The source is under WEB-INF (/web-inf/src/java/ ...), and the build >process is setup so you can work on it in place, without going through a >deployment phase. > >This would let us offer example, exercise, and documentation WARs, with >source, directly from the Web site where people could try them out as >pure applications, and take a peek at how things work. > >If this meshes with Martin's other plans, I could help with the >necessary changes. > >I'm also meaning to relabel "struts-simple" as a workflow example, since >that it what it has become. > >The new logon example (above) also includes using Velocity templates >with the nightly build, but doesn't use the latest version of the new >Velocity Tools, which is also compatible with Struts 1.0. > >http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ > >I've also been working on a new version of the Struts "blank" app, if >anyone is interested. > >http://husted.com/scaffolding/dist/blank.zip > >Basically the same thing, but with slightly different conventions and >(more importantly) a build file that includes options for JavaDocs and >building a WAR. I also hope to slip in some kind of stub for unit >testing soon, based on some other work I'm doing with Vincent. > > >-- Ted Husted, Husted dot Com, Fairport NY USA. >-- Building Java web applications with Struts. >-- Tel +1 585 737-3463. >-- Web http://www.husted.com/struts/ > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
