[kepler-dev] breaking off a kepler-docs repository
cxh at eecs.berkeley.edu
Tue Aug 9 16:50:14 PDT 2005
I agree that having the docs available via CVS is a win, especially
We split the Ptolemy II docs in to a separate repository awhile back
and it has been a total win. The user manuals are available as part
of the Windows installer, which most Ptolemy developers have on their
machines along with their CVS development tree.
I find it to be very useful to have the Ptolemy II tree not include
the docs when I'm checking out many trees to try to narrow down
a bug to just the few days when the change occurred.
I agree with Laura that it is somewhat less than convenient to have
the docs and the source in two trees. However, we have a slightly
different set up in that we have a source repository, a separate
repository for the Ptolemy manual framemaker files and then yet another
repository for papers that are being developed by multiple authors.
Talks and published papers go on to the web site and are not checked
in to CVS, though they could be.
One can always use wget to pull over an entire subdirectory of
the website and get the talks and papers.
Anyway, the above is my $0.02. I encourage you to split the
docs into a separate repository.
> The nightly build should be working again now. you probably saw the
> emails go by. Feel free to add any unit tests or workflow tests.
> Note that workflow tests with visual components (i.e. Display, Plot,
> etc) still won't run correctly until we get X working on the server
Locally, we are running Xvfb to provide X for some graphical tests.
My notes says
Xvfb is a virtual frame buffer that is installed on gigasource so that
the bldmastr user can run tests that use the X11 system.
* Download Xvfb for Solaris from
* Grab the install.xvfb and xvfb.server scripts from
* Edit xvfb.server. I needed to set X_OPTIONS to:
X_OPTIONS="-screen 0 1280x1024x32 -pixdepths 8 24 -fbdir /tmp -co $XVFB_DIR/rgb -fp $XVFB_DIR/fonts/misc/,$XVFB_DIR/fonts/Speedo/,$XVFB_DIR/fonts/Type1/,$XVFB_DIR/fonts/75dpi/,$XVFB_DIR/fonts/100dpi/ -sp $XVFB_DIR/SecurityPolicy"
* Run install.xvfb
* To test:
Testing and Troubleshooting Once the X server is running,
you can use your servlet application to confirm that Java
platform graphics are working. If you have trouble, check
that the X server is operating properly. As the user running
the X display (tomcat by default) follow these steps,
matching the value of -display to match your server:
% /usr/openwin/bin/xclock -display :2 &
You can use xwd (X window dump) to capture the image. Under
the Solaris 9 OE, I find that /usr/openwin/bin/xwd crashes
(see Sun bug id 4766571), so I use a copy I've obtained from
the X11 distribution that I've placed in /usr/X11R6/bin:
% /usr/X11R6/bin/xwd -display :2 -root -out /tmp/xclock.xwd
Then copy the image file over to another system and display
it to check that graphics are working, using xwud:
% /usr/openwin/bin/xwud -in /tmp/xclock.xwdY
If xclock won't run, then the server is probably not
running. Make sure that xsun.server or xvfb.server is
One thing I like about using CVS for document management is being able
to travel with everything and access all of the docs even when I am not
network connected. I find I often need access to powerpoint files and
word files in particular when I am on airplanes, and so I think whatever
solution we choose should allow a simple mechanism for downloading the
whole repository to local systems for offline access.
Otherwise, I would be fine with separating out a document repository.
Shawn Bowers wrote:
> I think it is a good idea to *not* include the various publications and
> presentations concerning Kepler in the code repository (cvs).
> I wonder, however, if having a separate cvs for documents is the way to
> go. Instead, maybe we should consider using a more traditional approach
> like a document management system? I'm sure there are a number of
> open-source/free ones out there (e.g., zope and plone are popular ones,
> the stanford publication server is an older one). Perhaps there are
> also extensions of the wiki for this?
> Chad Berkley wrote:
>>As I sit here checking out kepler (again), waiting forever for the docs
>>directory to finish, it occured to me that it might be ok to have a
>>different cvs repository for kepler docs. there's no reason why a
>>developer should have to checkout out a myriad of .doc and .ppt files
>>everytime you need a new version of kepler. It seems to me that docs
>>that actually go with the kepler software should stay in the kepler
>>repository, but publications, reports and the like could be stashed
>>somewhere else. Anyone have any reasons why this would be a bad idea?
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
More information about the Kepler-dev