db-jdo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jdo Wiki] Update of "TestingAndBuilding" by RichardSchilling
Date Fri, 12 Sep 2008 17:49:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jdo Wiki" for change notification.

The following page has been changed by RichardSchilling:
http://wiki.apache.org/jdo/TestingAndBuilding

------------------------------------------------------------------------------
  === 1. Familiarize yourself with the test environment ===
  
  
- You're going to save yourself a lot of time if you take a few moments to examine the directory
structure associated with the test code.  Actually, I just lied.  You're going to take more
than a few moments - you going take as much time as you need to visit each directory in the
test environment and get familiar the files and their reasons for being there.  Give yourself
a day or two to go through all that.
+ You're going to save yourself a lot of time if you take a few moments to examine the directory
structure associated with the test code.  Actually, I just lied.  You're going to take more
than a few moments - you going take as much time as you need to visit each directory in the
test environment and get familiar the files and their reasons for being there.  Give yourself
a day or two to go through all that.  And, as much as it sounds like you're getting lazy,
don't just rely on your command line tools and text editors to explore the JDO code base.
 You should use your favorite IDE just to cruise around the directory tree and familiarize
yourself with what you see.  
  
  
- You should use your favorite IDE just to cruise around the directory tree and familiarize
yourself with what you see.  My preferred way of working code on a project is to just use
the lowest common denominator of tools to get the job done.  This usually means the VI editor
for writing code, and build tools (e.g. compilers and repository management tools) that can
be run from a simple UNIX command line.  Keeping things simple like this means you don't need
more than that to get your work done, and quite frankly, it's a much more efficient way to
work because you don't have to mess around with windowing GUIs, IDEs and the like.  And, you
get the added benefit of having your working build environment be identical to the production
build environment (which runs nightly in batch on a different box).
+ My preferred way of working code on a project is to just use the lowest common denominator
of tools to get the job done.  This usually means the VI editor for writing code, and build
tools (e.g. compilers and repository management tools) that can be run from a simple UNIX
command line.  Keeping things simple like this means you don't need more than that to get
your work done, and quite frankly, it's a much more efficient way to work because you don't
have to mess around with windowing GUIs, IDEs and the like.  And, you get the added benefit
of having your working build environment be identical to the production build environment
(which runs nightly in batch on a different box).
  
  
  But, there are exceptions where using an IDE can help you learn what you need to learn about
a project as quickly as possible.  Working the JDO code is one such exception.  There are
a lot of files in the JDO code base, and it's helpful to have the IDE interpret the project
files and build scripts for you so it can lay things out graphically.  

Mime
View raw message