Re: Barracuda jars in cvs

I'm not sure I'd take any action before the 1.2.6 build.  It would require
changing the build.xml to account for this.  Let's leave things where they are
now and any concensus that comes out of this conversation can be applied to
later releases.  Again, I am neutral on this issue.  My main objection is that
if I have built Barracuda locally and then do a CVS update and you have updated
the jars since I have last updated, I get conflicts on the stored binaries. 
This is not a problem with 3rd party jars since they never change.  It is only
an issue with binaries that continually change.  My other objection is that
People use Different VM's.  If jars are built with JDk1.4.2, but the user is
running JDK1.3.1, the binaries may be incompatible.  There is no guarantee of
backward binary compatibility, but there is a guarantee of forward binary
compatibility.  Jars compiled with 1.3.1 will be binary compatible with all
future VM's, but not vice-versa.  As such, either we have to declare a minimum
VM and *always* store binaries compiled by that minimum or we are apt to cause
trouble for users of older VM's.

Anway, those are my issues.  The smaller size of CVS would be a nice by-product
of not storing the generated jars, but it is by no means the primary reason for
not storing them.

Jake

Quoting Christian Cryder <[email protected]>:

> 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