Re: Barracuda: Build system modifications

Hi Christian,

Whoops, somehow I missed this message since you sent it to the main list 
instead of BarracudaMVC so I'm a bit late at getting to it.

Anyway, see comments below....

At 08:13 AM 1/3/2003 -0700, you wrote:
>Hi Jake,
>
>Ok, first of all, I wanted to move this discussion back to the main
>Barracuda list so everyone can follow along.
>
>It seems to me that we're both speaking past one another on this issue - I
>suspect we both see clearly the advantages of our own approach, and are
>failing to see the pro's of the other person's approach. SO...at the risk of
>delaying our shipping out of the bmvc box by another day, I want to try and
>understand exactly what you're after, and hopefully better explain what I
>want to see. The goal here is to find some common ground that makes everyone
>happy, and get it right sooner rather than later.
>
>SO...to that end, here are a couple of key things that we decided waaaaay
>back which pertain to the build system (and hopefully an explanation of why
>I think they're important)
>
>First, we wanted it to be built with Ant. No contention here; Ant rocks and
>can handle just about any scenario we come up with. I think we all agree
>this was the right decision.

Yep, I don't even start a project without creating an Ant build for it first.


>Second, after much thought we chose to go with a rather unique directory
>structure (I haven't seen it done elsewhere) - we made the entire project a
>webapp, rather than putting the webapp portion further down into the tree.
>The idea here was relatively straightforward:  by making the whole project
>conform to a webapp structure, you always know where to point the URL -
>right at the root. This makes it easy to deploy, and it also makes it very
>easy to control access to stuff - anything that is public goes in the top
>level directory; anything provate goes beneath the src directory. Using this
>approach (combined with the fact that Barracuda is open source) it made
>sense to originally put the src in the topmost directory.

Yep, I remembered this, which was why I thought it rather odd that you 
wanted the src under WEB-INF.  But then you gave the reasoning that you 
wanted this to be a template for proprietary projects.  However, that 
really goes against the original decision to keep things open in the first 
place.  That being the case, the Barracuda build will *not* suit the needs 
of developers requiring a template for a proprietary build where they want 
to hide most things.  It is just antithetical to the fundamental design 
issues of the Barracuda build being open source.  I wanted to remedy this 
by moving the deployment root to a "build" directory which is created at 
build time.  In this case, you have the flexibility to copy in source or 
not.  It lends itself to a flexible build template without making any 
assumptions about the project being open source or proprietary.  It also 
solves the issue of server-locked jars.  I could go on, but I'll try to 
save a little for comments below...


>Now, originally we just had a src directory. Then we added a src_mockups
>which puts the template src into another directory. Most recently, we've
>been talking about adding a src_contrib. All this has made that root level
>directory a bit crowded, which was part of the reason I was thinking about
>moving it down under WEB-INF. If we do that it cleans things up a bit; it
>will also make it harder to link to src in examples, however. So, I'd
>actually be ok with leaving the src up in the current directory.

Well, if we created a "src" directory that contained other specific source 
directories underneath, you not have the root crowding problem.  This is 
soved, anyway, by separating the deployment root from the build 
system.  You have full control of where to copy source folders so you can 
link to it in the docs.  Or, in the proprietary case, you simply wouldn't 
copy the source to a public area.


>The key point that I want to make here is that I still feel very strongly
>that the whole project should conform to the webapp structure, rather than
>having a WEB-INF buried somewhere down in the bowels of the system, where
>you have to go find it.

I don't think that a "build" directory generated in the root of the project 
is considered "buried somewhere down in the bowels of the system".  It is 
sitting right there.  Now, if you are talking about the contrib projects, I 
solved that mostly by creating the build-contrib.xml which allows you to 
build all the contrib projects from the root level even though they are 
physically built "down in the bowels of the system".  I am fine with moving 
the contrib projects up higher in the directory structure.  I was just 
working within the constraints of the existing build system.  I think I 
came up with a pretty nifty solution given the constraints, IMO.


>Now, this kind of presupposes having only one webapp per major cvs module,
>and my suspicion here is that this is where we really start going different
>directions, so I'd like to try and flesh this out a little bit. The basic
>premise we started with originally was that the project would only have one
>webapp - if you really needed a separate one, then you'd split it out via a
>separate module, like BarracudaDiscRack, etc. SO...I'd like to dialogue on
>this: why is it that the contrib packages need their own webapps? Why not
>just a) keep them as part of the Barracuda webapp (the way we do with
>BConfig) or b) split them out as their own separate modules (the way we do
>with BarracudaDiscRack)? If you can give me some feedback on this, then
>maybe we can figure out how to better identify common ground on this one.

Because contrib projects contain both general use libraries which ought to 
be generally available and can be built within the normal Barracuda build 
*and* contributors have useful webapps to show off functionality of their 
libraries.  In addition, some contrib projects might only consist of a 
webapp using the normal Barracuda libraries, but also have some unique and 
useful techniques to show off.

BConfig and Admin apps are unique in that they can be built within the 
confines of the Barracuda system itself.  They are really sub-applications, 
though.  Not fully separate webapps.  The concept is, actually, quite 
inventive and I commend you for creating such a flexible concept of a 
movable app, static resources and all.  However, most times, webapps have 
too many unique things to just be in a .jar file.  They need their own 
separate webapp infrastructure from the web.xml to custom libraries...all 
the way to a custom build.  Mixing these with the current Barracuda build 
would just make it a big mess.  The separation allows flexibility from 
everyone.

Now, we could make these separate CVS modules.  I have no problem with 
that.  However, that wasn't possible when we were at e.org, so I made due 
with what we had to work with...building contrib webapps under the current 
source build structure.  Also, currently you can build and deploy (install) 
all the contrib projects with one command:

ant contrib -Dsubproject=all -Dsubtarget=install

If Tomcat is running, every existing contrib project which has a "webapp" 
folder in it will get installed in memory to Tomcat.  If we move each 
contrib project to its own module, we should write some mechanism to do 
these installations in a similar way.


>The third thing we intentionally decided way back was that the system needs
>to run straight out of the box; hence keeping the .jars under cvs in the
>/lib file. As per our previous discussions, there are some problems with
>this (Tomcat locks .jars, so cvs cannot update while Tomcat is running), but
>we have a solution for that that works quite well. The key is just that I
>should not need to build the system to run it - it should already be there
>for developers to use; one of the biggest reasons for doing this is that it
>makes it much easier to upgrade the project on the server (just update from
>cvs and cycle the service).

I forgot, what was that technique again?  Sorry, I've been very busy lately 
and I can hardly remember our conversation.  I don't think we really ever 
came to a conclusion on it.

One issue I have with this is that I *always* do a clean build because 
there are times when the jars don't get updated because one of us forgets 
to do it after we've updated a file.  Nobody is perfect.  In the case of 
updating the project, I don't see how running the ant build is such a 
burden.  You don't even need to do a clean. Just run the build and it will 
copy in the new jar files.  The only issues you have with locked jars it 
that you can't delete them, but you can always copy over them just 
fine.  The cycle the system like normal.


>I've got some other points (especially some ideas regarding deployment), but
>I'll wait to hear your response to these first...

Let me know your additional points.  The point I am making is that I never 
use Barracua as a build template for proprietary projects.  I us something 
akin to the system I've described (see the barracudamvc list).  It is 
flexible and doesn't assume all projects to be webapps.  The original 
assumptions that the Barracuda build system is based on are valid, but too 
inflexible.

Either way, if you want this out the door today with a decision made on the 
build system, I'm afraid we might just have to defer to your wisdom.  I'm 
just curious how the existing contrib infrastructure fare.

Anway, let me know what you think.

Jake


>Thanks!
>Christian
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Friday, January 03, 2003 1:39 AM
> > To: [email protected]
> > Subject: RE: [Barracuda] Stuff to Verify
> >
> >
> >
> > Hi Christian and Shawn,
> >
> > If we are going to change things, the I think an ideal way to set
> > things up is, first and foremost, make the generated build
> > separate from all of things so that what you are deploying is in
> > its own separate directory (see "build" below).  In this case,
> > there is no chance for the source to available to the outside
> > world (unless you explicitly copy it there).  In addition, it
> > provides for easy cleanup and doesn't confuse the build with the
> > structure of a webapp (which is important if the build is to be a
> > template for build in general and not just webapp builds).  So,
> > something like this is what I am thinking of (which is similar to
> > how Diez' contrib project is set up to work...within his webapp
> > directory)....
> >
> >
> > Barracuda/
> >     build.xml
> >     sample.build.properties
> >     version.properties
> >
> >     build/ (this is generated and is the deployment root of the
> > Barracuda app)
> >     dist/  (this is generated)
> >     generated/ (this is generated and is where all generated
> > sourcecode, etc... goes)
> >     bin/ (stores platform specific batch files)
> >     lib/ (stores general libraries...analogous to the old WEB-INF/jars)
> >     web/
> >         docs/
> >         dtds/
> >         assets/
> >             images/
> >             styles/
> >             scripts/
> >         WEB-INF/
> >             lib/
> >     src/
> >         script/
> >         mockup/
> >         java/
> >             contrib/
> >                 dbroggisch/
> >                 sam/
> >             core/
> >             plankton/
> >             webapp/
> >             log4j/
> >             taskdef/
> >             test/
> >             app/
> >                 admin/
> >                 config/
> >                 example/
> >                 testbed/
> >                 tutorial/
> >         webapp/ (apps under here are webapps separate from
> > Barracuda itself)
> >             contrib/
> >                 dbroggisch/
> >                 sam/
> >
> > The advantage of this is a simple structure and separation of concerns.
> > It also provides a simple way to do cleans.  The structure of the
> > src directory is debatable.  The main thing to take from it is how "src"
> > encapsulates all the source.  This also leaves things open for a
> > non-webapp
> > application...if you wanted to use this as a general build
> > template structure.
> >
> > I think this covers most everything that you mentioned as
> > advantages of your build structure and (IMO) improves on it in a
> > number of areas.  Let me know what you think of this.
> >
> > I'll look in the morning to see what you have proposed...after I
> > sleep in a bit.  After all, I have the day off :-)
> >
> > Jake
> >
> >
> > At 11:08 PM 1/2/2003 -0700, you wrote:
> >
> > Hi Jake,
> >
> > Ok...this is on my task list to address tomorrow morning
> > (Fri)...I'll spell out more fully then. In the meantime, the
> > short answer to all of this is ask the Q: "why change it from the
> > way we currently have it?"  If it works well, and people are used
> > to it, then the burden of proof is to explain why doing it a
> > different way is more compelling than the current approach (not
> > vica versa).
> >
> > The bottom line (IMO) is that
> >
> > a) Ant is flexible enough to handle and directory structure we
> > throw at it with relatively few changes to the build.xml file
> >
> > b) lots of projects have their own way of building things; there
> > is not a defacto "norm" to be following
> >
> > So I think the question of how we around things is largely going
> > to center around preferences, rather than one approach being
> > definitively better than another. I feel pretty strongly that the
> > current approach (keeping src, src_mockups, and src_contrib
> > separate) is solid - as Shawn said, it makes cvs control a bit
> > easier, and it means that your package structures can always
> > start directly underneath the src* dirs, rather than a level
> > deeper. I also feel that keeping the webapp structure at the top
> > of the tree _is_ better than putting the webapp dirs further down
> > inside the cvs tree (this was a conscious decision from very
> > early on in the Barracuda project, and I think its served us
> > well) But all of these are relatively minor things ultimately.
> > The real issue (again, IMO) is that there are not any real
> > "flaws" with the current way of doing things. SO...why change anything?
> >
> > Well, the biggest reason for wanting to move the src down under
> > WEB-INF is that if someone is going to copy the Barracuda
> > structure for their own project, they would probably not want the
> > src public (ie. it would make it easier for people to use as a
> > template). Plus, it seems cleaner for the Ant bat files to be in
> > a separate "bin" directory, rather than putting them in src
> > (since they operate on dirs like src_mockups that are at the same
> > level as src). But as Shawn pointed out, these are relatively
> > minor things.
> >
> > All this to say that I don't think the current approach is
> > overwhelmingly better than other alternatives, but I don't think
> > its underwhelmingly worse either - its really pretty
> > straightforward, and it works quite well. So unless there's
> > something really compelling that I am missing, I don't see why we
> > should change it drastically. By making the minor changes I'm
> > proposing (and I'll detail them tomorrow), I think we make the
> > structure cleaner and bring it a bit closer to a structure that
> > works well for proprietary projects as well.
> >
> > I don't know if that helps or not...feel free to respond, and we
> > can chat more about it tomorrow morning. The key is, I really
> > want to get the box shipped out tomorrow, so I'd like to avoid
> > spending a ton of time arguing over this. BUT...if we've got to
> > argue about it, it'd be better to do it now rather than later! :-)
> >
> > So anyway, let me know what you think. Cheers!
> >
> > Christian
> >
> >  -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Thursday, January 02, 2003 8:12 PM
> > To: [email protected]
> > Subject: RE: [Barracuda] Stuff to Verify
> >
> >
> >
> >
> > It has been a while since original discussions about the change
> > to the organization of the CVS source and I don't really remember
> > much about it.  The one thing I do remember is being
> > uncomfortable with the proposed organization.  Why move build
> > files to "bin"?  Why move source to WEB-INF/src?  If possible,
> > I'd like the proposal for the new organization spelled out with
> > an explanation as to what advantages it provides.
> >
> >
> > I think I remember one explanation and that was "it fits the way
> > NetBeans wan't it".  Well, I don't think that is a very good
> > reason.  The IDE should adapt to the source, not the other way
> > around.  Otherwise, you marry yourself and everyone else to a
> > particular IDE.  If the IDE isn't flexible enough to deal with a
> > source organization which makes sense to the community, then
> > throw away the IDE, not the build.  My opinion here is shared by
> > the main developers of Ant; Erik Hatcher and Steve Loughran who
> > are the authors of "Java Development with Ant" (see the Ant archives).
> >
> >
> > I'll try to do some thinking on this tomorrow, but I also need a
> > full explanation of the proposal.  I have a decent amount of time
> > and effort invested in the current build process and want to make
> > sure that, if it changes, it changes for the right reasons.
> >
> >
> > Christian, Shawn, and Mike, if you can provide reasoning for the
> > proposed changes, I can look at them tomorrow and give you some feedback.
> >
> >
> > One note.  Eric Hatcher has created a kind of reference for Ant
> > builds.  I will be looking at that tomorrow and evaluating
> > whether we might be able to leverage his ideas.  After all, he
> > is, pretty much, the undisputed expert.
> >
> > http://www.ehatchersolutions.com/JavaDevWithAnt/
> >
> > http://www.ehatchersolutions.com/downloads/JavaDevWithAnt-0.9.zip
> >
> >
> > Jake
> >
> >
> > At 04:00 PM 1/2/2003 -1000, you wrote:
> >
> > Hi,
> >
> > Maybe I'm moving ahead too fast, but I am working to build
> > barracuda from the CVS version I downloaded from barracudamvc cvs.
> >
> >   I moved all the build files into Barracuda/bin as Christian
> > recommended earlier.
> >
> > I made a couple of small changes to build.xml, and
> > version.properties to get the core to compile with the new paths
> > to src, and bin.
> >
> >   The issue I am facing now is with localize.  Everything
> > 'localizes' until I reach the tutorials, ( I believe it's the xml
> > grocery list example).
> >
> >
> >  ** Ant message **
> >
> > xmlc.sub:
> >
> >   [localize] Error: java.io.FileNotFoundException:
> > C:\Barracuda\bin\org\enhydra\barracuda\tutorials\xmlc\tutorials.xc
> > at (The system cannot find the path specified)
> >
> >
> >
> > It looks like it can't locate/resolve the xcatalog file.
> >
> > If I'm spinning my wheels, and should wait, -- that's okay.
> >
> >
> > I can send the changes to the ant files, if that will be helpful.
> >
> >
> > Thanks,
> >
> > Mike.
> >
> > _____________________
> >
> > Mike Warne
> >
> > [email protected]
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> >
> > From: Shawn Wilson [mailto:[email protected]]
> >
> > Sent: Thursday, January 02, 2003 1:24 PM
> >
> > To: [email protected]
> >
> > Subject: Re: [Barracuda] Stuff to Verify
> >
> >
> >
> >  > The only quirk I see is that barracuda-commit messages seem to require
> >
> >  > admin approval because I keep getting emails after commits saying that
> >
> >  > the email requires approval.  That should just be sent on through
> >
> >  > without approval.  Maybe [email protected] and/or [email protected]
> >
> >  > needs to be listed as subscribed to the commit list?  Not sure.
> >
> >
> > That's right. We just need to make sure all the commiters'
> >
> > *@barracudamvc.org email accounts are added as members to the
> >
> > barracuda-commit list, which hadn't been done but should now be taken
> >
> > care of.
> >
> >
> > -shawn
> >
> >
> > Jacob Kjome wrote:
> >
> > >
> >
> > > Ok,
> >
> > >
> >
> > > After Shawn made some changes, everything is working.
> >
> > >
> >
> > > The only quirk I see is that barracuda-commit messages seem to require
> >
> > > admin approval because I keep getting emails after commits saying that
> >
> > > the email requires approval.  That should just be sent on through
> >
> > > without approval.  Maybe [email protected] and/or [email protected]
> >
> > > needs to be listed as subscribed to the commit list?  Not sure.
> >
> > >
> >
> > > Jake
> >
> > >
> >
> > > At 01:42 PM 1/2/2003 -0600, you wrote:
> >
> > >
> >
> > >> Succeeded:
> >
> > >> a, b, f, g, h
> >
> > >>
> >
> > >> Partial Success:
> >
> > >> c, d
> >
> > >> I can access my email account via ssh'ing in and using Pine, but can't
> >
> > >> seem to access it via Eudora on Windows.
> >
> > >>
> >
> > >> Failed:
> >
> > >> I can't seem to commit anything.  I checked out via ssh just fine, but
> >
> > >> when I tried commiting COMMITTERS.txt it reported that I didn't have
> >
> > >> rights to commit the file.
> >
> > >>
> >
> > >>
> >
> > >> Jake
> >
> > >>
> >
> > >> At 11:05 AM 1/2/2003 -0700, you wrote:
> >
> > >>
> >
> > >>> Excellent!
> >
> > >>>
> >
> > >>> Ok, here are some things I need committer folks to validate:
> >
> > >>> ----------------------------------
> >
> > >>> If you are an admin or a committer, you should have ssh access to
> >
> > >>> barracudamvc.org...please respond to me or shawn asap if you don't
> >
> > >>> know your
> >
> > >>> acct name. Here's what I need you committers to do:
> >
> > >>>
> >
> > >>> a) verify that you can ssh into the box
> >
> > >>>
> >
> > >>> b) change your password to something besides the default
> >
> > >>>
> >
> > >>> c) as a committer/admin, you have an email account like <acct
> >
> > >>> name>@barracudamvc.org; you can receive any mail sent to this acct,
> >
> > >>> but as
> >
> > >>> far as sending mail goes, the server will only relay to mail accounts
> >
> > >>> on the
> >
> > >>> system (like the lists, etc). Make sure you can access this email
> >
> > >>>
> >
> > >>> d) committers, please check you barracudamvc.org email account as soon
> >
> > >>> as possible as it contains additional steps for you to
> > complete. You can
> >
> > >>> point your favorite mail client to barracudamvc.org, or use Pine when
> >
> > >>> you're logged in.
> >
> > >>>
> >
> > >>> Ok, now everyone should be able to do these:
> >
> > >>> ----------------------------------
> >
> > >>> f) you should be able to access the website at:
> >
> > >>>      http://barracudamvc.org <http://barracudamvc.org/>
> >
> > >>>
> >
> > >>> g) send mail to the list and get mail from it
> >
> > >>>
> >
> > >>> h) you should be able to check out the Barracuda cvs tree here (the
> >
> > >>> latest
> >
> > >>> version of Tortoise works great):
> >
> > >>>
> >
> > >>>     protocol:   pserver
> >
> > >>>     server:             barracudamvc.org
> >
> > >>>     repos dir:  /var/cvs
> >
> > >>>     module name:        Barracuda
> >
> > >>>     user:               anoncvs
> >
> > >>>     pwd:                anoncvs
> >
> > >>>
> >
> > >>> If you are checking it out via anonymous access, please
> > verify that you
> >
> > >>> CAN'T commit changes.
> >
> > >>>
> >
> > >>>
> >
> > >>> If you have problems with these steps, let us know immediately.
> >
> > >>>
> >
> > >>> That should be enough for now. Please try to complete these today
> >
> > >>> (1/2/03).
> >
> > >>> More instructions to follow.
> >
> > >>>
> >
> > >>> Christian
> >
> > >>>
> >
> > >>>
> >
> > >>>
> >
> > >>>
> >
> > >>>
> >
> > >>> Christian Cryder wrote:
> >
> > >>> > Excellent!
> >
> > >>> >
> >
> > >>> > Ok, here are some things I need committer folks to validate:
> >
> > >>> > ----------------------------------
> >
> > >>> > If you are an admin or a committer, you should have ssh access to
> >
> > >>> > barracudamvc.org...please respond to me or shawn asap if
> > you don't know
> >
> > >>> your
> >
> > >>> > acct name. Here's what I need you committers to do:
> >
> > >>> >
> >
> > >>> > a) verify that you can ssh into the box
> >
> > >>> >
> >
> > >>> > b) change your password to something besides the default
> >
> > >>> >
> >
> > >>> > c) as a committer, you have an email account like <acct
> >
> > >>> > name>@barracudamvc.org; you can receive any mail sent to this acct,
> >
> > >>> but as
> >
> > >>> > far as sending mail goes, the server will only relay to mail
> >
> > >>> accounts on
> >
> > >>> the
> >
> > >>> > system (like the lists, etc). Make sure you can access this email
> >
> > >>> >
> >
> > >>> > d) as a committer, you will also have access to the mailman admin
> >
> > >>> interface
> >
> > >>> > here:
> >
> > >>> >     http://barracudamvc.org/lists/admin/barracuda
> >
> > >>> > (there should be a pwd.txt in your home directory with the mailman
> >
> > >>> > password - this is for your reference; its up to you to keep this
> >
> > >>> current
> >
> > >>> if
> >
> > >>> > the pwd changes). The basic idea here is that the only reason you
> >
> > >>> should
> >
> > >>> > need to use this interface is to approve/deny messages that
> > get sent to
> >
> > >>> the
> >
> > >>> > list from unsubscribed folks - you shouldn't ever have to change the
> >
> > >>> > settings (and should probably refrain from doing so).
> >
> > >>> >
> >
> > >>> > Ok, now everyone should be able to do these:
> >
> > >>> > ----------------------------------
> >
> > >>> > f) you should be able to access the website at:
> >
> > >>> >     http://barracudamvc.org <http://barracudamvc.org/>
> >
> > >>> >
> >
> > >>> > g) send mail to the list and get mail from it
> >
> > >>> >
> >
> > >>> > h) you should be able to check out the Barracuda cvs tree here (the
> >
> > >>> latest
> >
> > >>> > version of Tortoise works great):
> >
> > >>> >
> >
> > >>> >    protocol:  pserver
> >
> > >>> >    server:            barracudamvc.org
> >
> > >>> >    repos dir:         /var/cvs
> >
> > >>> >    module name:       Barracuda
> >
> > >>> >    user:              anoncvs
> >
> > >>> >    pwd:               anoncvs
> >
> > >>> >
> >
> > >>> > If you are checking it out via anonymous access, please
> > verify that you
> >
> > >>> > CAN'T commit changes.
> >
> > >>> >
> >
> > >>> >
> >
> > >>> > Ok, more committer specific tasks:
> >
> > >>> > ----------------------------------
> >
> > >>> > i) if you are a committer, you should be able to use your committer
> >
> > >>> user/pwd
> >
> > >>> > when checking out from cvs.  Please update committers.txt and add
> >
> > >>> "[I WAS
> >
> > >>> > HERE]" beside your name in the file and then check it in to make
> >
> > >>> sure it
> >
> > >>> > works.
> >
> > >>> >
> >
> > >>> > j) to update barracuda from cvs log in via ssh simply type:
> >
> > >>> >     barracuda-update
> >
> > >>> >
> >
> > >>> > k) to cycle barracuda within tomcat simply type:
> >
> > >>> >     barracuda-cycle
> >
> > >>> >
> >
> > >>> >
> >
> > >>> > If you have problems with these steps, let us know immediately.
> >
> > >>> >
> >
> > >>> > That should be enough for now. Please try to complete these today
> >
> > >>> (1/2/03).
> >
> > >>> > More instructions to follow.
> >
> > >>> >
> >
> > >>> > Christian
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >
> >
> > >>> >>-----Original Message-----
> >
> > >>> >>From: [email protected]
> >
> > >>> >>[mailto:[email protected]]On Behalf Of Denny Chambers
> >
> > >>> >>Sent: Thursday, January 02, 2003 9:09 AM
> >
> > >>> >>To: [email protected]
> >
> > >>> >>Subject: Re: [Barracuda] Testing 1-2-3
> >
> > >>> >>
> >
> > >>> >>
> >
> > >>> >>I see you! Seems to working ok
> >
> > >>> >>
> >
> > >>> >>Christian Cryder wrote:
> >
> > >>> >>
> >
> > >>> >>>Hi guys...this is a test message to make sure you are receiving
> >
> > >>> >>
> >
> > >>> >>emails. If
> >
> > >>> >>
> >
> > >>> >>>you could reply to the list to confirm that you a) received the
> >
> > >>> >>
> >
> > >>> >>message and
> >
> > >>> >>
> >
> > >>> >>>b) can send mail to the list, I'd appreciate it.
> >
> > >>> >>>
> >
> > >>> >>>Here's who's currently subscribed:
> >
> > >>> >>>
> >
> > >>> >>>Christian - committer
> >
> > >>> >>>Shawn - master admin
> >
> > >>> >>>Denny Chambers - backup admin
> >
> > >>> >>>Diez Roggisch - committer
> >
> > >>> >>>Jacob Kjome - committer
> >
> > >>> >>>Mike Warne - anonymous user
> >
> > >>> >>>Steven Armbruster - anonymous user
> >
> > >>> >>>
> >
> > >>> >>>More to follow soon...
> >
> > >>> >>>
> >
> > >>> >>>CHristian
> >
> > >>> >>>
> >
> > >>> >>>----------------------------------------------
> >
> > >>> >>>Christian Cryder [[email protected]]
> >
> > >>> >>>Internet Architect, ATMReports.com
> >
> > >>> >>>Barracuda - http://barracuda.enhydra.org
> >
> > >>> <http://barracuda.enhydra.org/>
> >
> > >>> >>>----------------------------------------------
> >
> > >>> >>>"Coffee? I could quit anytime, just not today"
> >
> > >>> >>>
> >
> > >>> >>>_______________________________________________
> >
> > >>> >>>Barracuda mailing list
> >
> > >>> >>>[email protected]
> >
> > >>> >>>http://barracudamvc.org/lists/listinfo/barracuda
> >
> > >>> >>>
> >
> > >>> >>
> >
> > >>> >>_______________________________________________
> >
> > >>> >>Barracuda mailing list
> >
> > >>> >>[email protected]
> >
> > >>> >>http://barracudamvc.org/lists/listinfo/barracuda
> >
> > >>>
> >
> > >>> --
> >
> > >>> ====================================
> >
> > >>> Shawn Wilson [[email protected]]
> >
> > >>> Software Developer, ATMReports.com
> >
> > >>> PH: 877-327-0873, FAX: 406-294-5806
> >
> > >>> ====================================
> >
> > >>>
> >
> > >>> _______________________________________________
> >
> > >>> Barracuda mailing list
> >
> > >>> [email protected]
> >
> > >>> http://barracudamvc.org/lists/listinfo/barracuda
> >
> >
> > _______________________________________________
> >
> > Barracuda mailing list
> >
> > [email protected]
> >
> > http://barracudamvc.org/lists/listinfo/barracuda
> >
> > _______________________________________________
> >
> > Barracuda mailing list
> >
> > [email protected]
> >
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/barracuda
>FAQ - http://www.jguru.com/faq/Barracuda