Contrib structure

Hi folks,

I'd like to take this opportunity to start a conversation on how best to
structure the contrib stuff on the new server. Basically, what we have right
now is something like this:

/Barracuda
  /src
    /org/enhydra/barracuda...
      ...
      /core (core packages)
      /contrib
        /dbroggisch
           /display (source)
           /dtd
           /repopulation (source)
           /webapp
             /docs
             /src
             /src_mockups
             /web
               /WEB-INF
        ... (other contributors)
  /WEB-INF
    /lib-cvs (this is where the jars are kept)

Right now, when you build the contrib package, the classes get compiled into
the main Barracuda /WEB-INF/classes directory, and are then eventually
jarred into the main WEB-INF/lib-cvs/barracuda-contrib.jar. I'd like to keep
this working this way, since it keeps all the actual source attached to the
main Barracuda project.

Now, where things get murky (IMO), is that the way things are currently
structure, Diez's contrib structure also contains a sample webapps, with
docs, etc. This is the part I find confusing, since its ultimately rooted
under Barracuda's /src directory (and its really not source at all).

SO...what I'd like to propose is that we structure our cvs tree like this:

  /var/cvs...
    /Barracuda
    /BarracudaDiskRack
    /Contrib
      /dbroggisch (webapp)
        /docs
        /WEB-INF
      /christianc (webapp)
        /docs
        /WEB-INF
      /hoju
        /Sample1 (webapp)
          /docs
          /WEB-INF
        /Sample2 (webapp)
          /docs
          /WEB-INF

The basic idea here is that

a) anyone can get their own contrib directory under the Barracuda tree...add
your code there, and it'll get automatically included into the
barracuda-contrib.jar

b) anyone who wants to set up sample webapps that demonstrate their code can
then get their own contrib directory under the Contrib cvs tree...they could
have one webapp or many; its totally up to them. They could also use
whatever build system or format they want.

I think this would give us maximum flexiblity to experiement with various
approaches, while keeping the overall Barracuda src tree relatively clean.

One of the keys to making this work would be to adopt Jakes ccf.xml method
for installing webapps into tomcat...then, every app (including Barracuda)
could register with Tomcat without us having to constantly edit the
server.xml file.

These are just my initial thoughts...comments and feedback welcome!

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"