Re[2]: updated BarracudaDiscRack!

Hello Shawn,

See comments below...

Thursday, February 06, 2003, 10:05:54 AM, you wrote:

SW> Hey Christian,

SW> Just to make sure I understand what you're saying, here's my take of 
SW> what needs to happen (correct me if I'm wrong):

SW>     1. Create a "contrib" CVS module.
SW>        a) Only committers may create first-level subfolders, thereby 
SW> creating a "space" that a contributor will own.
SW>        b) Only the contributor may commit to their space. Or should 
SW> committers also have the ability to commit anywhere in contrib?

I feel that the main committers should have full access to everything.
However, it will be understood that the contrib projects are mostly
hands-off unless there are build problems.  Very few other reasons
should require the need for a general committer to do anything to the
contrib projects.  One other ones I can think of is if a contributor is
no longer active.  We need someone to have access to this stuff.  The
projects will lose their meaning if they fall out of date with the
current Barracuda releases.  We need a way to ensure the apps keep up
without depending on any one contributor.

SW>     2. Remove src_contrib from the Barracuda module.

I'm not sure what you mean by this?  Do you mean remove the
org.enhydra.barracuda.contrib package?  That is not something being
proposed.  What is being proposed is moving the
contrib.[contributorName].webapp structure from the Barracuda module.
This means that the core reusable classes stay under the Barracuda
module so they are actually available for use.  The new contrib
modules are for examples showing usage of various contrib packages or
just nifty general Barracuda apps.

OR

We could fully remove the contrib package from the main Barracuda
module and make it so that the main build.xml for the new contrib
module will build any and all general packages creating the
barracuda-contrib.jar distribution.  This would mean we'd need to make
sure that set up a way to ensure that barracuda-contrib builds against
some specified release of Barracuda (probably the latest release).

Anway, this needs to be discussed.  Since the only contrib package we
are currently moving is Diez', this should be relatively
straightforward.

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

What do you mean by "target directory from deployment"?  With the
build technique of using the ccf.xml file for installing or deploying
to Tomcat, there is no need for such a concept of a pre-conceived
deployment directory.  catalina-install installs apps to memory.
catalina-deploy provides for permanent deployment across server
restarts.  Neither requires any outside directory analogous to
Tomcat's CATALINA_HOME/webapps directory to provide for this.

If you need me to clarify this, please let me know.  Or maybe I'm just
not understanding what you are saying?

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

Are you suggesting something like
http://barracudamvc.org/contrib/~[username] ?

I'll have to think about how the current catalina ant tasks will work
with this idea.

The other way to do something like this is to set each project up with
a build that uses CATALINA_BASE and starts up a new instance of Tomcat
for each webapp.  However, this might not be scalable on a single
machine since it will take up many times the memory that one instance
of Tomcat would.

SW> Does that about sum it up?

SW>  > (ps - we also need to get a downloads directory working...maybe we
SW>  > create a /production/Downloads webapp, which is not part of cvs, but
SW>  > which has all the daily / main builds in it. Thoughts?

SW> I recommend something like /var/production/releases. Then within this 
SW> space I think we would have "milestone" releases along with daily 
SW> builds. My goal for the releases is:

SW>     1. The process is mostly (fully?) automated
SW>     2. Every release compiled & test cases executed under all JDK/JVM 
SW> versions we support.
SW>     3. For "milestone" releases, we provide a summary of changes (a 
SW> changelog) since the last milestone release.

Denny's experimentation with AntHill should lead to automation of
this.

Jake

SW> What does everyone else think?

SW> -shawn

SW> 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

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



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