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