Re: RE: Barracuda jars in cvs

Quoting Christian Cryder <[email protected]>:

> Darn it! I wasn't quite done! Stupid Outlook sent it before I was ready...
> ;-)
> 
> To complete my thought:
> 
> SO...that's the basic rundown. I'd be curious to hear what people
> think: should we remove the following jars from cvs:
> 
> WEB-INF/lib-cvs/admin.jar
> WEB-INF/lib-cvs/config.jar
> WEB-INF/lib-cvs/contrib.jar
> WEB-INF/lib-cvs/core.jar
> WEB-INF/lib-cvs/examples.jar
> WEB-INF/lib-cvs/testbed.jar
> WEB-INF/lib-cvs/tutorials.jar
> WEB-INF/lib-cvs/plankton.jar
> 
> The upshot of this will be that you can no longer simply type
> 
>     'ant install'
> 
> when updating from cvs, yout instead you will have to do
> 
>     'ant clean' (or 'ant superclean')
>     'ant jars' (or 'ant jars.master')
>     'ant install'
> 
> and this in turn means you will have to have all the proper 3rd party jar
> files / jdk stuff in place on your box in order to actually do the compile.
> 

continuing from my other email, I never suggested we remove all binaries from
Barracuda.  I do have a way to automatically download dependencies, though,
which would allow for this (kind of like how Maven works, but in an Ant build).
   Until that happens, I have no problem storing 3rd party jars in CVS.  I only
have a problem with storing generated jars.  And, again, I wouldn't do anything
until *after* the 1.2.6 release.

Jake

> Let me know what you think...
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
> 
> 
> > -----Original Message-----
> > From: Christian Cryder [mailto:[email protected]]
> > Sent: Tuesday, February 03, 2004 10:39 AM
> > To: [email protected]
> > Subject: Barracuda jars in cvs
> >
> >
> > Hi Thelmo & Jake,
> >
> > Here's the history on this (complete details are in the
> > archives...this has been discussed in the past)
> >
> > Originally, the goal of the Barracuda project was that it would
> > install out of the box. This is why the whole project is
> > structured as a webapp. You simply unpack the project or update
> > it from cvs, point your appserver at it and bang! you're in
> > business. Pretty simple, and I think a very proper goal (you'll
> > notice there are very few complaints over the last three years
> > from people saying "I can't get this thing to run")
> >
> > Now, this is why we started storing the jars under cvs - so that
> > you could unpack the project and simply run it. For this reason,
> > the jars were originally kep in the WEB-INF/lib directory. The
> > problem with this approach, however, is that if you are updating
> > from cvs, cvs will want to delete those files before putting the
> > new copies in place, and if Tomcat is running, it has them
> > locked. SO...what ended up happening was that you'd have to shut
> > tomcat down in order to update from cvs.
> >
> > So what we did next was moved all the jars from WEB-INF/lib to
> > WEB-INF/cvs, and then add the ant install task, which copies the
> > jars from /lib-cvs to /lib (you can overwrite locked files
> > without a problem). The install task also copies sample files
> > into place (like web.xml, object-repository.xml, etc). The upshot
> > of all this is that you can update from cvs, install, and then
> > just quickly cycle just the webapp to pick up new changes. Much
> > less down time, far less invasive, etc. Plus you still didn't
> > have to rebuild the project.
> >
> > Given all this, I still like the idea of keeping all the jar
> > files in cvs. It keeps Barracuda relatively easy to use - you
> > just update from cvs and run install (no need to rebuild the
> > jars). There are several complications however. Jake has added
> > the notion of superclean, which clears out the copied sample
> > files so that they can be recreated anew when you do the next
> > install. This is good, since there are times when you want to do
> > this (like when sample.xml changes). Superclean also nukes the
> > jar files under cvs, so that they will be rebuilt (guaranteeing
> > that what's in the jars is what's in your src tree...shouldn't be
> > necessary if the jars are updated regularly, but that hasn't been
> > happening all the time). Another issue is that we never use the
> > Barracuda jars that are kept under cvs anyway - we also build
> > using the jars.master target so that we can get the single
> > unified barracuda.jar (which used to be under cvs before we split
> > the jars up into pieces).
> >
> > SO...all this to say, we can revisit the idea of removing the
> > Barracuda generated jars from cvs. But the implications of this
> > are going to be that it will further complicate the install
> > process - you will have to update from cvs and then
> > compile/build/jar/install. Second, one of the most common reasons
> > people ask to have the jars removed from cvs is to save on
> > project size (faster updates from cvs). I personally think this
> > is mostly a non-issue: if you look at all the jars which are
> > under cvs, we have over 8 MB of 3rd party jars (ouch!), while the
> > Barracuda jars account for less than a meg. So, removing the jars
> > from cvs may not speed things up nearly as much as people might expect.
> >
> > There are other issues as well - namely deployment (the basic
> > premise that when deploying apps you should never be recompling,
> > but always installing a previously compiled/tested binary which
> > is kept under cvs. For our projects that use Barracuda, we keep
> > everything under cvs, and the installation process is a breeze -
> > all fully automated through ant, even the cycling of Tomcat...so
> > we'd never move our other projects away from keeping jars under
> > cvs). That said, Barracuda is a library, not a vertical app...so
> > if people really want to remove the jars from cvs, it wouldn't
> > kill us (like I said, we are already rebuilding jars to use the
> > unified barracuda jar, rather than all the individual barracuda jars).
> >
> > SO...that's the basic rundown. I'd be curious to hear what people
> > think: should we remove the following jars from cvs:
> >
> > WEB-INF/lib-cvs/
> > WEB-INF/lib-cvs/
> > WEB-INF/lib-cvs/
> > WEB-INF/lib-cvs/
> > WEB-INF/lib-cvs/
> >
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------
> > Christian Cryder
> > Internet Architect, ATMReports.com
> > Project Chair, BarracudaMVC - http://barracudamvc.org
> > ----------------------------------------------
> > "Coffee? I could quit anytime, just not today"
> >
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]On Behalf Of Thelmo Loisio
> > > Sent: Monday, February 02, 2004 4:31 AM
> > > To: [email protected]
> > > Subject: RE: [Barracuda] New version tagged in cvs
> > >
> > >
> > > On Sat, 2004-01-31 at 02:30, Jacob Kjome wrote:
> > > > At 09:11 AM 1/30/2004 -0500, you wrote:
> > > > >Hi Thelmo,
> > > > >
> > > > > > Could it be the right time (now before release) to remove
> > > the various
> > > > > > compiled jar files from CVS repository !?
> > > > >
> > > > >What exactly do you mean? Not sure I clearly understand what
> > > you have in
> > > > >mind here...
> > > > >
> > > > >Christian
> > > >
> > > > I'm pretty sure he means stuff like barracuda-core.jar and
> > > family.  Those
> > > > jars that are generated by the Barracuda build itself and are
> > > not 3rd party
> > > > dependencies.  I have suggested removing them in the past, but
> > > I know your
> > > > arguments for keeping them in CVS.  I'd be happy enough if they went
> > > > bye-bye, but I'd leave that completely up to you and the rest of the
> > > > community.  It would certainly make it much faster to grab the
> > > Barracuda
> > > > CVS and not worry about committing jars, just code updates.
> > > >
> > > > Jake
> > > >
> > >
> > > Yes, Jacob get my point.
> > > Christian which are your arguments to keep that jar in the repository !?
> > >
> > >
> > > --
> > > Thelmo
> > >
> > > _______________________________________________
> > > Barracuda mailing list
> > > [email protected]
> > > http://barracudamvc.org/lists/listinfo/barracuda
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda