RE: Contrib structure

Hi Jake,

Yes, I like the idea of having a common build point in the Contrib
module...I think basically all we need to do is make sure each sub-project
(or each contritors directory) provides an Ant file that supports clean,
compile, jars, and maybe the deployment/installation options for Tomcat. We
can figure out the details on this...

> Also, do we want to impose the latest and greatest CVS on the contrib
> projects?  That is what happens currently.  I think this is also a

I _don't_ think we should impose the latest and greatest on what's
underneath the Contrib cvs module; I _do_ think we should on the contrib
code that's in the Barracuda tree. That gives people the ability to upgrade
their Contrib trees as they have time, but it forces the actual contrib code
in the Barracuda tree to stay up date.

As I re-read this email, I can see how we might want to come up with
different terminology to distinguish between the "contrib" (little c)
directory in the Barracuda src tree, and the "Contrib" (big C) cvs module
that I proposed in my earlier email...maybe it should be something like
this:

  /var/cvs...
    /Barracuda
    ...
    /Public
      /dbroggisch
      ...

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: Thursday, January 16, 2003 1:24 PM
> To: Christian Cryder
> Subject: Re: [Barracuda] Contrib structure
>
>
> Hello Christian,
>
> For the most part, it seems like a pretty good idea.  The one thing
> that the current contrib structure allows for is for one to simply
> call...
>
> ant contrib -Dsubproject=all -Dsubtarget=compile
>
> This compiles all the source in Barracuda (included the contrib
> stuff), jars everything (including the barracuda-contrib.jar) and then
> builds every contrib project which has a "webapp" directory.
>
> Will there be a way to do a batch build of all contrib projects in the
> new scheme?  I suppose this could still be done by putting build file
> in the "Contrib" directory.  However, the advantages of this would
> have to be weighed against the disadvantage of requiring some
> standards for the build process.  If we allow people to write whatever
> build scripts they want, it might be a little hard to do things in
> batch like I currently have things set up.
>
> So, I guess I'm pretty ok with the proposed structure.  I'd just like
> to hash out the details of whether we will impose some standard build
> process or just let everyone run wild with their own builds.  Having
> some standards which people work within will broaden possibilities of
> controlling the builds externally.  I think that is a good thing.
> Also, do we want to impose the latest and greatest CVS on the contrib
> projects?  That is what happens currently.  I think this is also a
> good thing because it keeps the apps current.  If they break because
> of the new stuff, we either fix a bug in the new stuff or updated the
> apps to work with the newer/better/faster latest CVS.  I wouldn't do
> this in production (well, I kind of mostly do anyway), but it is
> reasonable to do it in this case because if stuff falls behind, it
> becomes irrelevant.
>
> What do others think?
>
> Jake
>
>
> Thursday, January 16, 2003, 1:50:47 PM, you wrote:
>
> CC> Hi folks,
>
> CC> I'd like to take this opportunity to start a conversation on
> how best to
> CC> structure the contrib stuff on the new server. Basically,
> what we have right
> CC> now is something like this:
>
> CC> /Barracuda
> CC>   /src
> CC>     /org/enhydra/barracuda...
> CC>       ...
> CC>       /core (core packages)
> CC>       /contrib
> CC>         /dbroggisch
> CC>            /display (source)
> CC>            /dtd
> CC>            /repopulation (source)
> CC>            /webapp
> CC>              /docs
> CC>              /src
> CC>              /src_mockups
> CC>              /web
> CC>                /WEB-INF
> CC>         ... (other contributors)
> CC>   /WEB-INF
> CC>     /lib-cvs (this is where the jars are kept)
>
> CC> Right now, when you build the contrib package, the classes
> get compiled into
> CC> the main Barracuda /WEB-INF/classes directory, and are then eventually
> CC> jarred into the main WEB-INF/lib-cvs/barracuda-contrib.jar.
> I'd like to keep
> CC> this working this way, since it keeps all the actual source
> attached to the
> CC> main Barracuda project.
>
> CC> Now, where things get murky (IMO), is that the way things are
> currently
> CC> structure, Diez's contrib structure also contains a sample
> webapps, with
> CC> docs, etc. This is the part I find confusing, since its
> ultimately rooted
> CC> under Barracuda's /src directory (and its really not source at all).
>
> CC> SO...what I'd like to propose is that we structure our cvs
> tree like this:
>
> CC>   /var/cvs...
> CC>     /Barracuda
> CC>     /BarracudaDiskRack
> CC>     /Contrib
> CC>       /dbroggisch (webapp)
> CC>         /docs
> CC>         /WEB-INF
> CC>       /christianc (webapp)
> CC>         /docs
> CC>         /WEB-INF
> CC>       /hoju
> CC>         /Sample1 (webapp)
> CC>           /docs
> CC>           /WEB-INF
> CC>         /Sample2 (webapp)
> CC>           /docs
> CC>           /WEB-INF
>
> CC> The basic idea here is that
>
> CC> a) anyone can get their own contrib directory under the
> Barracuda tree...add
> CC> your code there, and it'll get automatically included into the
> CC> barracuda-contrib.jar
>
> CC> b) anyone who wants to set up sample webapps that demonstrate
> their code can
> CC> then get their own contrib directory under the Contrib cvs
> tree...they could
> CC> have one webapp or many; its totally up to them. They could also use
> CC> whatever build system or format they want.
>
> CC> I think this would give us maximum flexiblity to experiement
> with various
> CC> approaches, while keeping the overall Barracuda src tree
> relatively clean.
>
> CC> One of the keys to making this work would be to adopt Jakes
> ccf.xml method
> CC> for installing webapps into tomcat...then, every app
> (including Barracuda)
> CC> could register with Tomcat without us having to constantly edit the
> CC> server.xml file.
>
> CC> These are just my initial thoughts...comments and feedback welcome!
>
> CC> Christian
> CC> ----------------------------------------------
> CC> Christian Cryder [[email protected]]
> CC> Internet Architect, ATMReports.com
> CC> Barracuda - http://barracuda.enhydra.org
> CC> ----------------------------------------------
> CC> "Coffee? I could quit anytime, just not today"
>
> CC> _______________________________________________
> CC> Barracuda mailing list
> CC> [email protected]
> CC> http://barracudamvc.org/lists/listinfo/barracuda
>
>
>
> --
> Best regards,
>  Jacob                            mailto:[email protected]
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda