RE: Barracuda: Build system modifications

Hi Jake,

Ok, I'm back now. I'll try to pick up where I left off.

> A webapp build structure, I presume.  Not everything is a webapp.

Actually, no. Everything I've been talking about pretty much presumes that
we're talking webapps. I think that's a fairly safe assumption given that
Barracuda is primarily aimed at the webapp space. Plus, these days almost
everything has a "web page interface", even if its not actually a webapp in
and of itself. I was just trying to differentiate between "reusable
framework" and an "end user application" (which might make use of many
frameworks). So my comments were simply to the effect that Barracuda as it
currently stands is a better example for a framework style project than for
a production webapp (where I think the dev vs. deploy distinction becomes
very important).

> Well, throw out all other reasons and just use this one simple reason:
>
> <target name="clean">
> <delete dir="build"/>
> </target>
>
> It doesn't get much simpler than that to do a full clean.  Also,
> if you don't do a full clean, you can end up resources, classes,
> and jars that shouldn't be in the build.  For instance, say you
> built something or copied something, then you rename it on the
> src side of things.  The original copied resource still exists
> where you copied it and the only way you are going to make sure
> the system is fully synced up is to do a full clean build.  Just
> counting on copying instead of doing a clean is problematic.  I
> *always* do a clean.  I don't care if the system is pre-built on
> checkout.  I'm going to do a clean build anyway.

Sorry, but the light didn't go on for me here. The build.xml already has a
clean target in it; so I don't understand how changing the directory
structure really changes that. Are you saying that your approach does
cleaning better? Or are you saying that you should never rely on prebuilt
.jars?

If the latter, I'd just have to disagree with you; I think that's one of the
things that has made Barracuda so easy for people to use - you simply check
it out (or download the zip) and point your appserver at it and you're good
to go; you shouldn't _have_ to build anything. Nothing, nothing precludes
you from rebuilding (we always do, prior to upgrading our internal projects
to a new version of Barracuda) - you just shouldn't _have_ to in order to
use the framework.

To apply this back to the notion of deploying (from my previous discussion),
we operate on the premise that when we want to deploy a particular version
of a webapp, everything needed for that app should already be in cvs
(including the jars) - nothing should need to be built on the target system;
just check it out from cvs, run the install procedure, and go. Like I said,
we haven't observed any problems with this - if anything, its actually
provided a much higher degree of certainty that what the developer actually
tested against is precisely what's going to get deployed on the production
machine.

> It forces the semantics of what your app is all about.  If you
> put it under WEB-INF, well, you app is quite obviously a
> "webapp".  However, if I am going to have a generalized build
> template for all kinds of projects, I don't want to force, these
> semantics.  It also defeats the purpose of the original intent of
> Baracuda being an open source project where the source is fully
> viewable by the public.

I'd argue that Barracuda's primary focus has always been the webapp space;
even for non-webapp frameworks, you'd still probably want to have some kind
of webapp "project view" interface. But that's really beside the point - the
simple fact of the matter is that our mission here is not to build the
mother of all build systems (at least I'm not concerned with trying to do
that) - we just need a build system that works well for Barracuda and any
code that it contains. That's our primary objective. As a secondary
objective, I think it'd be nice to follow a format that looks similar to
something people building webapps and using Barracuda might want to
replicate for themselves. I really think its a mistake to expand our scope
beyond just the webapp space here.

As far as making the source publically viewable - we need to keep in mind
that moving it under WEB-INF just doesn't mean that its hidden (you can
always view it via cvs, download, etc); it just means that its not viewable
directly via a web browser. And I'd wager that not too many people are
viewing Barracuda source that way anyway...most are probably using the
actual source or the cvs archives.

> /MyApp
>     /MyAppDeploy
>         /WEB-INF
>             /lib (not under cvs)
>             /lib-cvs
>     /MyAppDev
>         /docs
>         /WEB-INF
>             /bin
>             /src
>             /src-mockups
>             /lib (not under cvs)
>             /lib-cvs
> ...
> This is almost exactly the concept of the "build" directory
> except that, given the fact that you never delete MyAppDeploy,
> you may have left over cruft.

Everything under MyAppDeploy is under cvs; so we don't really have a problem
with cruft - the developer might possibly forget to add a new jar, but our
deployment procedure catches that (we check out and test a version before
deploying on a production box).

My whole point with this, however, is that _framework_ type code really does
not need the rigor of a separate dev vs. deploy mechanism, because a
developer is going to choose when to upgrade all his projects to the latest
version of Barracuda - he's probably not going to do it on a daily basis.

> I still don't like the semantic stranglehold you put on your
> builds by putting src in WEB-INF.  Again, not everything is a
> webapp and I don't want it deployed until I am ready anyway and
> that *always* means doing a clean build, IMO.

But this is just for Barracuda. And that's a webapp. We're not forcing
anyone else down this path. I'm just trying to make things clean and
intuititive (and I think that either way - whether the src is in the top
level dir or WEB-INF - its still pretty intuitive).

> Haven't you every tried Diez' app?

No, I haven't...the past 4 mths have been really busy. :-( Ok...hold
on...there! I just did now, and everything worked fine - I really like the
way you automatically install the app; the process is easy and smooth (so
that much is good)!

Now, here's what I don't like...check out the path to Diez's examples stuff:

...\Barracuda\src\org\enhydra\barracuda\contrib\dbroggisch\webapp\src\org\en
hydra\barracuda\contrib\dbroggisch\examples

We have packages within packages, so to speak. I find this very confusing -
under the Barracuda src tree, we suddenly have a whole bunch of stuff that
isn't src at all. Plus the actual location of the java files is scattered
about in several different places. Look at all the places where we find src:

...\Barracuda\src\org\enhydra\barracuda\contrib\dbroggisch\display
...\Barracuda\src\org\enhydra\barracuda\contrib\dbroggisch\repopulation
...\Barracuda\src\org\enhydra\barracuda\contrib\dbroggisch\webapp\src\org\en
hydra\barracuda\contrib\dbroggisch\examples

So for me, this is very confusing - I would probably need documentation to
understand what's going on here; it doesn't seem very intuitive at all.
Maybe other people find it plain as day, but it sure confuses me.

Ok, so in light of all this discussion, I think we can safely conclude that
there are lots of different ways of doing builds and that many of us are
going to have significantly different opinions on how best to go about it.
So...here's what I'd like to propose:

a) I think we should leave the Barracuda tree as it currently is (not moving
the src trees from the top level under WEB-INF); I think we do still need to
move the cvs jars into a lib-cvs, but that is a very minor change.

b) I think we should consider moving all the contrib projects out into their
own cvs modules. This means that our cvs module structure would look
something like this:

/Barracuda
/BarracudaDiscRack
/Contrib
    /dbroggisch
    /christianc
    etc.

This would then make it really easy for contrib packages to use whatever
build structure they want, and would also keep the master source tree much
simpler. Plus, it's still relatively easy for Shawn to administer in terms
of permissions.

SO...what do you think? Jake? Shawn? Anyone?

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