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