cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: Gump and CocoonDev
Date Sun, 16 Mar 2003 14:52:06 GMT
Steven Noels wrote:
> Sam Ruby wrote:
>> Ultimately, we'll have to discuss what groups people are assigned to 
>> and whether or not /etc/bashrc should be modified so that umask is set 
>> to 002 for everybody.  What we need to ensure is that there is no 
>> problem with permissions of files that people create.
> umask isn't automatically set to 002 - I'll see this eventually gets 
> changed (I've been suggesting to people to change it in 
> ~/.bash_profile). All 'system-wide capable' people are in the cocoondev 
> group, there are some other people who are only in project-specific groups.
> If other account owners want to be in the cocoondev group 
> to help Sam out, please indicate so. Currently, there's Jeff, Bruno and 
> Marc, Ovidiu, Sylvain, Tom Klaasen, Sam, and myself. I just added David, 
> too.

At the present time, the various cocoon blocks have gone from yellow 
(prereq failed) to red (build failed).  These are now unblocked because 
the core build of cocoon now successfully produces a jar.  Yea!  They 
fail because these project definitions don't include a dependency on Ant 
(or Xerces for that matter).  These project definitions also don't 
contain nag entries.

If somebody wants to make a change and test it out on cocoondev, simply 
update cocoon-2.1/gump.xml and issue the following two commands on

	build gump scripts
	build cocoon-block-html

You will find 'build' and a few other useful scripts and utilities in 
/usr/serverlocal/gump/bin.  Add this to your PATH.

Since the project definitions for cocoon's core and blocks are not in 
gump's cvs but are defined to be retrieved from cocoon's cvs, an extra 
step is required: namely to commit these changes before building.

> Since quite a few people are in multiple groups, and cocoondev isn't 
> necesseraly their primary group, so some chgrp might be needed when you 
> create new files.

Making people take extra actions to 'do the right thing' invites problems.

Let me describe how I would like to encourage this shared resource being 
used.  I gave an example above: make a change and try it out.  Build one 
project then build another that depends on it.  No need to worry about 
classpaths or copying jars - all that is taken care of for you. 
Whatever change you make is immediately effective.

Make a change any way you like - for example, directly edit the files 
using your favorite editor, or simply do cvs update commands.  Being 
able to do a cvs update with a "-D date" option is particuarly powerful 
- you can roll back changes made to projects you depend on and rebuild 
first that project and then cocoon.  With a simple binary search over 
dates, you can isolate and identify the precise change that broke you. 
If you are so inclined, make a fix, verify that it works, and send a 
patch to the owners.

Don't worry too much about how you leave things.  Every night (currently 
at midnight CET), the cocoondev will update to the latest from cvs and 
these directories will be restored via efficient 'rsync' commands and 
rebuilt.  In fact, if you mess things up too much, simply rm -rf the 
project directory and do a build - the contents will automatically be 
restored to the last cvs checkout.

What this requires is that whatever id is used to execute the nightly 
builds has ability to update any files that people might produce.  Umask 
002 is an important part of ths - and making sure that I (or whoever is 
running the nightly build) am in the all the primary groups of everybody 
who might create files in this directory is another.

I'm still tweaking and improving, but don't be shy.  Go forth and play.

> Document root is /www/ which is owned by 
> rubys, group cocoondev
> </Steven>

View raw message