> > 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.
Just tripped over that site the other day. There is just too much
to read and too little time to do it in! hehehe...I love it. Means
these technologies are amazing, and they truly are.
> > * 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.
<target name="reload" description="Does a light reload of the application">
<taskdef name="reload" classname="org.apache.catalina.ant.ReloadTask"
classpath="${tomcat.home}/server/lib/catalina-ant.jar"/>
<echo message="Reloading Application ${ant.project.name}..."/>
<reload url="http://${tomcat.server}:${tomcat.port}/manager";
username="${tomcat.username}" password="${tomcat.password}" path="/${webapp.name}"/>
</target>
The rest are pretty much the same. Just replace reload with start, stop,
deploy, remove and so on. I have only really used reload, start and stop.
> > * 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.
I just meant so that I could keep them in the library repository so
that when they upgrade it grabs them as well. Didn't really have a
plan for it though.
> 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.
Oh, graphics designers, God help them are hopeless. I tried for 2
weeks to get him to understand CVS and finally gave up. I check in
all the changes now until I can work with someone who knows what
he/she is doing. Argh, designers. 'course, they probably say the
same thing about us.
> 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.
Hmm, I like the sandbox idea. You spawned something in my mind and
I am going to run with it. Here goes. I can create a set of
sandbox tasks. After running a build I can use the task
'build-sandbox' which basically just unwars the war file into a
sandbox directory and reloads the tomcat application (so the context
xml file is pointing to my sandbox at this point). Then, I can go
in and make any changes to graphics, jsps, css or js. Anything
non-code related. Then, I have a task called 'commit-sandbox' which
basically pulls any changed files from the sandbox back into the web
tree to be included in the next build (is there a diff task for
ant??). This way, I am using the sandbox with a pull technique and
I am not interfering at all with the appfuse setup (except to have
these two special ant tasks!). I think it is a damn good idea.
Then you can make changes to the live application (even if it is on
the test server, live as in you can see it in the browser) and then
you can commit the changes back to your tree without much work. I
will get started on that and maybe ;) you will consider it!
Dan
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Daniel Allen, <[EMAIL PROTECTED]>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rumour has it that bad dreams about Windows can be ended by
putting on a pair of Tux slippers and clicking your heels
together 3 times while saying.
"There's no place like /home."
"There's no place like /home."
"There's no place like /home."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------------------------------------------------
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
