portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johnny Cass <johnny.c...@epiuse.com>
Subject Re: Problem with log4java (was: Branching for release)
Date Thu, 07 Jun 2001 08:24:40 GMT
Santiago Gala wrote:
> Johnny Cass wrote:
> > Santiago Gala wrote:
> >
> >>
> >>Also, I'm seeing funny things with current CVS.
> >>
> >>- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
> >>
> >
> > The current build system does not add jetspeed.jar to the war. Instead,
> > the jetspeed classes are compiled into the 'classes' directory which
> > *is* distributed with the war. As far as I know, the net effect should
> > be the same (both are added to the classpath of the webapp).
> >
> OK. Since I had two errors mixed up, I will try without jetspeed.jar to
> see if/how it works.
> The problem I see with this setup is that we can no longer build and
> then move the jetspeed.jar to the tomcat directory. 

The 'jar' target creates a jetspeed.jar. So, you could use 'war' to
create the webapp, copy this to ${tomcat.home}/webapps, run tomcat to
expand the war, delete the 'classes' directory, and then copy the
jetspeed.jar created by target 'jar' into WEB-INF/lib on subsequent
builds. Alternatively, you could simply replace the classes directory
for the jetspeed webapp in tomcat with the one under

Having said this, I must admit that it sounds like way too much trouble.
I usually use soft links to accomplish the same effect.

> How do you manage
> incremental builds? Do we have a target where we can specify a webapp
> target directory for ant to copy the compiled files (and maybe content)
> there, w/o building and expanding the war under tomcat?

I usually set a soft link from ${jetspeed.cvs.root}/webapp to
${tomcat.home}/webapps/jetspeed and one from
${jetspeed.cvs.root}/bin/classes to
${jetspeed.cvs.root}/webapp/WEB-INF/classes. So, in effect, I am running
Jetspeed direct from my CVS repository. I'm sure somebody can educate me
on the perils of this approach! ;).

> Expanding the war destroys any permanent changes done by customization,
> the cache, etc.

I'm open for suggestions, it doesn't really make a difference either
way. We will need to have a 'classes' directory regardless of the
approach taken since the 'cactus.properties' file needs to be in the
webapp's classpath.

- Johnny

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message