RE: updated BarracudaDiscRack!

>     1. Create a "contrib" CVS module.

yes

>        a) Only committers may create first-level subfolders, thereby
> creating a "space" that a contributor will own.

yes

>        b) Only the contributor may commit to their space. Or should
> committers also have the ability to commit anywhere in contrib?

I would say either contributors or committers. The only real reason for this
is that it makes it easier for a committer to help a contributor (or if we
have to change something in the api, then we can go update the contributor
code as well).

>     2. Remove src_contrib from the Barracuda module.

I didn't think we have a src_contrib, do we? Or do you just mean the contrib
directory under core? I would envision leaving
\src\org\enhydra\barracuda\contrib, so that the contributor source tree
still gets checked out (and can be built) as part of of the Barracuda tree;
but the contributor webapp stuff (as well as any source that might
demonstrate how to use the contributor's classes) get's put in the new
contrib webapps directory.

So basically, what this is saying is "try and keep contrib classes that are
_framework_ level classes in the Barracuda tree, but keep all the supporting
stuff in the contrib webapp portion of cvs". This allows for contributors to
play around with build systems, set up examples, and even do test
development in their webapp directory - just the parts that are relevant to
the framework itself would actually get placed in the Barracuda tree.

In Diez's example (since he's the only one with a contrib directory at this
point), most of the stuff under contrib/dbroggisch would stay where it is -
just contrib/dbroggisch/webapp would move to the new location.

>     3. Create a target directory for deployment. I recommend /var as the
> root and then using Christian's proposed structure, i.e.
> /var/production/Barracuda, etc.

Yes. This works for me. So we'd have

/var/production/Barracuda
/var/production/BarracudaDiscRack
etc.

Anything under /var/production (except for the contrib dir) would be an
"officially recognized" webapp.

Everything else would go under /var/production/contrib/<contributor
name>/...

>        a) Contributors will have the ability to deploy their projects
> into their own space under /var/production/contrib. If they have
> webapps, these will be publicly available from the website
> (http://barracudamvc.org/contrib?).

Yeah, I guess we could do that, or if we're using the ccf.xml approach, I
guess they can specify whatever URL name they want. Good practice would
probably be something like <contributor name>/<webapp name>.

As an example...let's say the contrib dir looked something like this:

.../contrib
       /dbroggisch
           /FormsExample (webapp)
           /Test1 (webapp)
       /christianc
           /Test1 (webapp)
           /Test2 (webapp)
           /Test3 (webapp)
       /joesomebody (webapp)

the urls might be something like this:

http://barracudamvc.org/dbroggisch/FormsExample
http://barracudamvc.org/dbroggisch/Test1
http://barracudamvc.org/christianc/Test1
http://barracudamvc.org/christianc/Test2
http://barracudamvc.org/christianc/Test3
http://barracudamvc.org/joesomebody

This makes it so folks don't have to worry about stomping on one another.

That help? Or did I just muddy up the waters?

> I recommend something like /var/production/releases. Then within this
> space I think we would have "milestone" releases along with daily
> builds. My goal for the releases is:
>
>     1. The process is mostly (fully?) automated
>     2. Every release compiled & test cases executed under all JDK/JVM
> versions we support.
>     3. For "milestone" releases, we provide a summary of changes (a
> changelog) since the last milestone release.
>
> What does everyone else think?

Sounds good.

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

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Shawn Wilson
> Sent: Thursday, February 06, 2003 11:06 AM
> To: [email protected]
> Subject: Re: [Barracuda] updated BarracudaDiscRack!
>
>
> Hey Christian,
>
> Just to make sure I understand what you're saying, here's my take of
> what needs to happen (correct me if I'm wrong):
>
>     1. Create a "contrib" CVS module.
>        a) Only committers may create first-level subfolders, thereby
> creating a "space" that a contributor will own.
>        b) Only the contributor may commit to their space. Or should
> committers also have the ability to commit anywhere in contrib?
>     2. Remove src_contrib from the Barracuda module.
>     3. Create a target directory for deployment. I recommend /var as the
> root and then using Christian's proposed structure, i.e.
> /var/production/Barracuda, etc.
>        a) Contributors will have the ability to deploy their projects
> into their own space under /var/production/contrib. If they have
> webapps, these will be publicly available from the website
> (http://barracudamvc.org/contrib?).
>
> Does that about sum it up?
>
>  > (ps - we also need to get a downloads directory working...maybe we
>  > create a /production/Downloads webapp, which is not part of cvs, but
>  > which has all the daily / main builds in it. Thoughts?
>
> I recommend something like /var/production/releases. Then within this
> space I think we would have "milestone" releases along with daily
> builds. My goal for the releases is:
>
>     1. The process is mostly (fully?) automated
>     2. Every release compiled & test cases executed under all JDK/JVM
> versions we support.
>     3. For "milestone" releases, we provide a summary of changes (a
> changelog) since the last milestone release.
>
> What does everyone else think?
>
> -shawn
>
> Christian Cryder wrote:
> > Hey Jake, thanks for getting this working! Can you work with
> Shawn today
> > to get BarracudaDiscRack running on the bmvc.org site? I think
> it should
> > be relatively simple to do...
> >
> > Also, we need to move the webapps out from underneath the
> Tomcat default
> > webapps directory, and into their own location (this because we need to
> > have public contrib directories as well)...so perhaps something
> like this
> >
> > (root)
> > /production
> >     /Barracuda                    (webapp)
> >     /BarracudaDiscRack      (webapp)
> >     /contrib
> >         /dbroggisch               (might contain one or more webapps)
> >         /christianc
> >         ...
> >
> > Of course we will also need to set up the cvs tree to match this...my
> > basic thinking is that anyone should be able to request (and
> get) access
> > to their own personal project space under the contrib directory, and
> > have full access to this part of the cvs tree. So let's say Joe
> Somebody
> > requests contrib space, we'd give him a spot under
> > /var/cvs/contrib/joesomebody, and he will have full write privileges
> > there, even if he hasn't earned committer rights on the main trees.
> >
> > I really don't care about the directory names/structure...so
> I'm open to
> > whatever modifications you want to make Shawn. I'd just like to see us
> >
> > a) get the webapps stuff out from underneath Tomcat
> > b) start installing webapps using the ant + ccf.xml approach,
> so that we
> > don't have to touch the server.xml file
> > c) allow for public contrib directories (which themselves might have
> > multiple webapps beneath them (this allows for people to
> experiment with
> > different build structures
> > d) make it easy for people to check out (and build) all contrib
> packages
> > - ie. checkout contrib and you get everything beneath it, and maybe we
> > put a master build.xml file in the contrib directory that will
> build all
> > the projects beneath it - we can work out those details)
> >
> > Thoughts? Denny might be available to help with this as well...
> >
> > Christian
> >
> > (ps - we also need to get a downloads directory working...maybe we
> > create a /production/Downloads webapp, which is not part of cvs, but
> > which has all the daily / main builds in it. Thoughts?
> > ----------------------------------------------
> > Christian Cryder [[email protected]]
> > Internet Architect, ATMReports.com
> > Barracuda - http://barracudamvc.org <http://barracudamvc.org/>
> > ----------------------------------------------
> > "Coffee? I could quit anytime, just not today"
> >
> >     -----Original Message-----
> >     *From:* [email protected]
> >     [mailto:[email protected]]*On Behalf Of *Jacob Kjome
> >     *Sent:* Thursday, February 06, 2003 1:06 AM
> >     *To:* [email protected]
> >     *Subject:* Re: [Barracuda] updated BarracudaDiscRack!
> >
> >
> >     Hi everyone,
> >
> >     I just wanted to note that Denny Chambers reported that the discrack
> >     app wasn't compiling.   It turned out that it compiled fine with
> >     Jikes (which is what I was using) but not with javac.  So, I guess
> >     the moral of the story is to make sure to check that both compilers
> >     work against any code that is to be checked in.  I've made the
> >     change to allow javac to compile.  I tagged CVS with jrk_20030205.
> >     So, everything should work now.
> >
> >     here is what I wrote in the comments for the checkin for those who
> >     are curous what the error was....
> >
> >
> > compile was failing using the "modern" javac
> > compiler.  I had done all testing with jikes which always
> > succeeds.  The error was:
> >
> > compile.project:
> >     [javac] Compiling 18 source files to
> > D:\myclasses\repository\enhydra\Barracu
> > daDiscRack_2003-02-05\BarracudaDiscRack\WEB-INF\classes
> >     [javac]
> > D:\myclasses\repository\enhydra\BarracudaDiscRack_2003-02-05\Barracu
> > daDiscRack\src\org\enhydra\barracuda\discRack\DiscRackGateway.java:40:
> > package o
> > rg.enhydra.barracuda.core.util does not exist
> >     [javac] import org.enhydra.barracuda.core.util.*;
> >     [javac] ^
> >     [javac] Note:
> > D:\myclasses\repository\enhydra\BarracudaDiscRack_2003-02-05\B
> >
> arracudaDiscRack\src\org\enhydra\barracuda\discRack\data\disc\DiscDO.java
> > uses o
> > r overrides a deprecated API.
> >     [javac] Note: Recompile with -deprecation for
> > details.
> >     [javac] 1 error
> >
> > I removed the import line:
> > import org.enhydra.barracuda.core.util.*;
> >
> > That fixed the error for the javac compiler.  I still don't
> > understand why because that package does exist but, oh well, it works
> > now.
> >
> > Jake
> >
> >
> >
> >
> >
> >     At 06:02 PM 2/3/2003 -0600, you wrote:
> >
> >>     Hi everyone,
> >>
> >>     I have updated the BarracudaDiscRack application.  It now compiles
> >>     against the latest Barracuda CVS.  Specifically, it compiles
> >>     against the Barracuda CVS with the tag "jrk_20030203".  I also
> >>     tagged BarracudaDiscRack with that same tag.
> >>
> >>     The build now works in a very similar way to Barracuda....only it
> >>     is only meant to build one application instead of all the extra
> >>     stuff that the Barracuda build has to do.
> >>
> >>     One nice thing (among many) about the new build process is the
> >>     automatic setup of discRack.conf with the appropriate path to the
> >>     database.  To install to Tomcat-4.1.x, just do the following:
> >>
> >>     1.  Grab the latest BarracudaDiscRack CVS
> >>     2.  Make sure Tomcat is started and CATALINA_HOME has been set in
> >>     your environment.  Make sure xerces-1.4.4-xmlc-2.1.jar exists in
> >>     CATALINA_HOME/shared/lib or common/endorsed
> >>     3.  run "ant catalina-install"
> >>
> >>     That will build and install BarracudaDiscRack from wherever it is
> >>     on your file system.
> >>
> >>     So, there you go.  Please report any problems.  I may do some
> >>     tweaks later.  The docs have not been updated, but shouldn't be
> >>     too far off.  I'm gong to take a break from it for now, so all I
> >>     will do is make bugfixes to the build and application as a whole.
> >>     Hopefully someone else can take up modifying the docs.
> >>
> >>     Jake
> >>
> >>     _______________________________________________
> >>     Barracuda mailing list
> >>     [email protected]
> >>     http://barracudamvc.org/lists/listinfo/barracuda
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda