Re: 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]