Re[2]: Contrib structure

Hello Denny,

I'm not sure how the /~username stuff works in Tomcat, but if we can
use the Ant manager tasks to install the apps, we should be able to
install them to the /~username paths.  I'd rather not physically store
the apps under Tomcat.  They should be separate and installed/deployed
externally and that can be done through existing mechanisms that
already work that way in the Barracuda build and the contrib builds
(dbroggisch build only, currently).

Also, as far as moving the main barracuda-contrib stuff completely out
of the Barracuda build, I know it would made it easier to control CVS
access and all, but I'm not sure it is good for the contrib projects'
visibility.  Many people would be grabbing only Barracuda and not the
Contrib module.  the barracuda-contrib.jar has lots of stuff that is
generally useful and should be given lots of visibility.  I don't
think this will happen if it exists outside of the main Barracuda
module.

I like the idea of putting docs in a separate module.  I think we
should also do some sort of XDocs so that the actual docs aren't
filled with presentation nonsense.  It is very difficult (without
resorting to an ugly tool like Microsoft Frontpage) to edit the actual
content of the docs by looking at the source.  It should be simple to
create and modify docs with a plain text editor and the naked eye.  We
can then use XSLT to turn it into any presentation format we
want...including PDF!

Jake

Thursday, January 16, 2003, 2:17:08 PM, you wrote:

DC> I like this approach better. My first thought was to see if contributors 
DC> could get their own account on the server. Then we could setup 
DC> apache/tomcat to allow user directories (like 
DC> www.barracudamvc.org/~dennyc - i believe this possible with tomcat). 
DC> This way each contributor would be able to set up there own web space 
DC> (Web apps, docs, source, binaries) under there user directory. My 
DC> preference would be to keep contrib stuff seperate from the Barracuda 
DC> CVS module. So my vote is to keep the contrib stuff totally seperate, so 
DC> that users can download the contrib code totally seperate from the CVS 
DC> (from each contrib user personal directory as a zip file), or that the 
DC> contrib stuff becomes a seperate module in CVS. By atleast making it a 
DC> seperate module, it will allow you to do finer grain access control to 
DC> cvs (developer can have access to contrib module, but not the Barracuda 
DC> module).  I would also like to recommend making the barracudamvc.org web 
DC> pages a seperate module, since that would allow you to assign access to 
DC> folks, who want to work on the web site, documention, or demos. Just a 
DC> suggestion.

DC> Denny

DC> Christian Cryder wrote:

>>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"
>>
>>_______________________________________________
>>Barracuda mailing list
>>[email protected]
>>http://barracudamvc.org/lists/listinfo/barracuda
>>
>>
>>  
>>

DC> _______________________________________________
DC> Barracuda mailing list
DC> [email protected]
DC> http://barracudamvc.org/lists/listinfo/barracuda



-- 
Best regards,
 Jacob                            mailto:[email protected]