> First of all, the idea of having a supporting library repository and > a cooresponding lib.properties file which maps those libraries is > ingenious. I was spending a lot of time upgrading my jar files when > a new version of struts or hibernate was released because I could > not remember what I needed, what version I had and why I needed that > jar file. Now I just drop the new jar file into my lib repository, > update my lib.properties file and the next build includes the > updated file. Awesome.
This is actually from Erik Hatcher's example app for JavaDevWithAnt - so I can't take any credit. I *do* like it, though it's kindof a pain to remove/add versions from CVS. Maven makes this easier with their repository. I guess if Hibernate didn't release so often, it wouldn't be much of an issue?! It is nice to be able to simply back-out an upgrade though. > Changes: > > Here are some of the changes I think need to be made to make the > appfuse build process more extensible. > > * create a consistent src.dir property so that the path to the > sources directory is not hardcoded throughout the build process > Easy change - but why? I think "src" is standard enough - don't you? Like I said, an easy change, I've had this before, and never really saw the point. > * make use of the start, stop and reload tasks from catalina-ant.jar > instead of undeploying, restarting and deploying the jar file each > time. I've actually been sent this from someone and believe I lost it. I'll have to dig though my e-mail and see if I can recover it. > * Make a spot to specify supporting tag library jar files What do you mean by this? Currently, all I'm doing is putting the tag library jar files in WEB-INF/lib and using their URL in common/taglibs.jsp. > Finally, I wanted to bring up an concept I am still stuck on. As it > stands now, I run my application using a context xml file in the > tomcat webapps directory and a custom docBase. This way, after > building my war file I extract it to a directory of choice and > reload the application (prevents having to redeploy the war file). > However, my issue is that I have to go through the whole build > process each time a make a change to a jsp, graphic or stylesheet > file. This just seems dumb, even frustrating for my designer, who > has to ask me to rebuild so he can see his changes. I am trying to > work this one out. To resolve it the build directory has to also be > the repository for the jsp/js/graphics files. I guess it could be > done by using a mask of **/*.jsp **/*.css **/*.jpeg **/*.jpg > **/*.gif **/*.png and so on. If I can figure this one small part > out I will be really cooking. I have already overwritten my changes > too many times to count since I like to see the change right away, > so I make the change in the deployed directory, then rebuild and > overwrite those changes. Oops. Maybe I am just trying to do > something too specific. Who knows, shed light? Is your graphics designer checking in their changes to CVS? I use the "deploy-web" task, and this simply deploys my the static files from my web/ directory. I would suggest that even the designers have Tomcat installed and can deploy/test/etc. their changes. If you're using Anthill to constantly run your tests, then you will know if you "broke the build" so you don't have to hear it from your designers. Since I do most of the UI work on my projects, I usually test new images, javascript or css by creating a "sandbox" directory. Then I run the app, view source, and save the page I want to change in this directory. I find/replace the context path (i.e. /appfuse/) with "../web/" and I can operate on everything statically - works pretty slick and is much faster than deploy/login/test. HTH, Matt __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Struts-apps mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/struts-apps
