Re: Barracuda: Moving the src directory

I agree with Jake on both counts.  I too set up my projects as he describes 
and it works great.  It makes more sense to me to build from the root 
directory and have the web root stuff a directory below, rather than the 
other way around.

Ron


-----Original Message-----
From: Jacob Kjome
Sent: Monday 09 December 2002 7:58 am
Subject: RE: Barracuda:  Moving the src directory

> Ok, how about separating out the entire build area and building kind of
> like I have things set up in Diez' contrib project.
>
> You end up having a structure like:
>
> Barracuda/
>      build (created at build time)
>      docs
>      src
>      src_generated (created at build time)
>      src_mockups
>      web/
>          WEB-INF/
>              jars
>              lib
>
> The the "web" directory is pretty much just copied whole over to the
> "build" directory.  When we want to do a "clean", all we have to do is
> delete the build directory and the src_generated directory.  Nice and
> easy.  Much simpler than having to remove various generated files that may
> have been generated or copied to areas where we want to keep most things
> and only remove a few things.
>
> Any thoughts?
>
> I just think this would make builds easier.  It solves the locking issues
> and keeps the source and the build completely separated.  This is how I do
> *all* my personal builds.
>
> Also, I can live with storing Barracuda generated jars in CVS.  I still
> don't like it.  A full build of Barracuda takes 47 seconds on my new
> machine so it isn't such a big deal for me to do a clean build.  I *always*
> do a clean build anyway since it isn't always guaranteed that the jars are
> as up-to-date as the source.  The reason being that we are human and forget
> to update the jars sometimes, even though we should.  It is a maintenance
> issue.  Everything should build fine at all times anway.  Like I said,
> nightly builds would be there if you want the jars and if you grab a tagged
> version of the CVS (assuming it compiled successfully at one time) the
> compile should be guaranteed to work resulting in working jars.  If it
> provides benefits for you to keep them in CVS, I guess that's fine.  I
> would get rid of them if the choice were completely up to me.  I don't know
> of any other project that keeps non-third-party jars in CVS.
>
> Jake
>
> At 10:20 PM 12/8/2002 -0500, you wrote:
> >Hi Jake,
> >
> > > Don't we lose all the history by moving the directory?  That
> > > wouldn't be a good thing to happen.  If we can do it without
> >
> >Nope. We can do it without losing any history. Shawn's already tested it
> > out to verify.
> >
> > > directory exists.  However, doesn't this limit the documentation
> > > when linking to the relevant sourcecode?  You can't link to
> >
> >Yeah, that would be a drawback, although probably not a real major one. We
> >could always link to the source through the cvsweb interface, so it'd
> > still be there. Or we could copy the text up to the docs directories if
> > need be. Let me think about it...
> >
> > > Sounds fine, although you'll still have a problem with the <copy>
> > > of the jar files from the lib-cvs to lib because if the file
> > > dates on the files in lib are newer than those obtained via cvs,
> > > they won't be copied over....or maybe that is a good thing if the
> > > files in lib contain updates that don't exist in cvs?  Well,
> >
> >The basic idea is that the files never get copied over unless the dates
> > are newer (which they would be if you rebuild the jars and update cvs).
> >
> > > Well, either way, I don't like the idea of storing non-third-party
> > > libraries in cvs.  I can see where people might like the idea of
> > > being able to obtain the libs without having to perform a build,
> > > but that is really what nightly builds are for.
> >
> >The biggest reason for doing it this way is so that you can tag a
> > particular version of cvs and then check out based on that tag, and know
> > that you have a running version of the system without having to do a
> > compile. Which makes it reeeeeeally easy to update the version on the
> > server. Otherwise you end up with a situation where you go to update the
> > server, it does a
> >clean/rebuild and something breaks, and now you have to figure out how to
> >recover.
> >
> > > it brings up this whole issue
> > > of the cvs "update" failing because it can't delete libs that are
> > > stored in cvs and locked by the server.
> >
> >Actually, by using a lib-cvs approach, the jar files that are under cvs
> > are never actually locked, so it really isn't a problem.
> >
> >We can figure out all the details as we go forward, but for now I just
> >wanted to answer some of your basic questions.
> >
> >Christian
> >----------------------------------------------
> >Christian Cryder [[email protected]]
> >Internet Architect, ATMReports.com
> >Barracuda - http://barracuda.enhydra.org
> >----------------------------------------------
> >"Coffee? I could quit anytime, just not today"
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > > Sent: Sunday, December 08, 2002 2:40 PM
> > > To: [email protected]
> > > Subject: Re: Barracuda: Moving the src directory
> > >
> > >
> > >
> > > Hi Christian,
> > >
> > > See comments below...
> > >
> > > At 04:54 PM 12/7/2002 -0500, you wrote:
> > >
> > > Hey folks, as we get ready to move things over to the BarracudaMVC
> > > server, we're going to be doing some much needed housecleaning. One of
> > > the things I'd like to do is move the src directory down underneath
> > > WEB-INF. It was orginally placed up in the content directory so that
> > > people could browse it
> > > online, but since the online cvs interface does a much better job of
> > > handling that anyway, I'd like to move it down underneath WEB-INF. Does
> > > anyone object to that?
> > >
> > >
> > > Don't we lose all the history by moving the directory?  That
> > > wouldn't be a good thing to happen.  If we can do it without
> > > losing the history, I really don't much care where the src
> > > directory exists.  However, doesn't this limit the documentation
> > > when linking to the relevant sourcecode?  You can't link to
> > > anything existing beneath WEB-INF unless you front the webapp
> > > with Another web server and don't enforce not being able to see
> > > under WEB-INF.  And doing such a thing is not good practice
> > > anyway.  I'm just wondering what the real benefits from moving
> > > the src directory are?
> > >
> > >
> > > Also, I'd like to move the build.xml stuff and the .bat files out
> > > of the src
> > > directory and into WEB-INF/bin, if nobody objects. The idea would be
> > > then that you'd go to WEB-INF/bin to build the system.
> > >
> > >
> > > There is probably no issue with this except for the concerns I
> > > already outlined above.  Actually, if we are going to move things
> > > around, we might want to create a "source" directory and then
> > > beneath that have stuff like "bin", "java", "javascript", etc....
> > > just to demarcate the different types of source that we have
> > > instead of lumping it all in to one java-centric package structure.
> > >
> > >
> > > Finally, one additional change will be to create a WEB-INF/lib-cvs
> > > directory, and to place all the jars that are under cvs in here,
> > > rather than
> > > in WEB-INF/lib. There would still be jars in the lib directory, but
> > > they won't be under cvs. The reason for doing this is so that you can
> > > update your
> > > Barracuda installs from cvs _without_ having to shut down Tomcat (when
> > > cvs updates, it tries to delete files before replacing them, and it
> > > can't do that to files in /lib because Tomcat has them locked). So the
> > > way it works then is you a) update from cvs and b) install (which
> > > copies jars from WEB-INF/lib-cvs to WEB-INF/lib. We've been using this
> > > strategy for about 4 mths now here at ATMReports, and its worked quite
> > > well.
> > >
> > >
> > > Sounds fine, although you'll still have a problem with the <copy>
> > > of the jar files from the lib-cvs to lib because if the file
> > > dates on the files in lib are newer than those obtained via cvs,
> > > they won't be copied over....or maybe that is a good thing if the
> > > files in lib contain updates that don't exist in cvs?  Well,
> > > either way, I don't like the idea of storing non-third-party
> > > libraries in cvs.  I can see where people might like the idea of
> > > being able to obtain the libs without having to perform a build,
> > > but that is really what nightly builds are for.  If we diligently
> > > produced nightly builds, then storing the jars in cvs becomes
> > > truly pointless.  It both unnecessarily increases the time to do
> > > a "checkout" of the latest cvs and it brings up this whole issue
> > > of the cvs "update" failing because it can't delete libs that are
> > > stored in cvs and locked by the server.  There is no reason this
> > > issue should exist.  I say lets completely get rid of any
> > > Barracuda-built jars from storage in cvs.
> > >
> > >
> > > If anyone has any comments on this, please speak up! I'm not planning
> > > on making these changes in existing cvs tree, but would put them in
> > > place on the new server.
> > >
> > >
> > > Let me know what you think.
> > >
> > > Jake
> > >
> > >
> > >
> > > Christian
> > > ----------------------------------------------
> > > Christian Cryder [[email protected]]
> > > Internet Architect, ATMReports.com
> > > Barracuda - http://barracuda.enhydra.org
> > > ----------------------------------------------
> > > "Coffee? I could quit anytime, just not today"
> > >
> > > _______________________________________________
> > > Barracuda mailing list
> > > [email protected]
> > > http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> > > FAQ - http://www.jguru.com/faq/Barracuda
> >
> >_______________________________________________
> >Barracuda mailing list
> >[email protected]
> >http://www.enhydra.org/mailman/listinfo.cgi/barracuda
> >FAQ - http://www.jguru.com/faq/Barracuda


_______________________________________________
Barracuda mailing list
[email protected]
http://www.enhydra.org/mailman/listinfo.cgi/barracuda
FAQ - http://www.jguru.com/faq/Barracuda