I'm following up on
a thread that was mentioned some time ago about how people handle vendor drops,
dependencies, and stepping into vendor source during debugging of a working copy
of your own code.
Others mentioned
that they would be interested in the process I use to keep it all straight, and
I'm attaching two documents that help explain what I do, as well as the
vendors.build file I am currently using on one of my projects that uses
Castle.
In addition to
those documents, I have a comment, and a disclaimer:
1. The process is
inherently brittle, as it relies on my manually maintaining my vendors.build
file properly. Any change in the upstream source/dependency, and things can get
real messy very quickly. Something that could manage this automatically would be
great, but I have yet to find something like Maven for .NET (although I did find
a Maven plug-in for .NET, it's not the same thing).
2. This is a work
in progress, and as such, I'm very open to suggestions. Be gentle.
:)
THE
PROCESS:
The goal of the
process is to be able to step into vendor code, at will, if the vendor source is
available. In addition, one should be able to switch dependencies from debug to
release with relative ease.
The key to this
process is the vendors.build file.
To ensure you can
switch dependencies from release to debug and back again, you use the
vendors.build to purge and recreate a vendors library directory, which is the
only location for dependencies outside of your own source. Basically, regardless
of whether the dependencies derive from source or are from a binary
distribution, they end up in the same location, "vendors/lib", and then
categorized by the NAnt function "${framework::get-target-framework()}", i.e.
"vendors/lib/net-2.0".
Within the
vendors.build file you have targets which can build either release or debug of
the vendor source, with whatever granularity you desire. As well, the
vendors.build file is responsible for updating the shared/vendors library
directories of the vendor sources themselves, just in case one of your vendor
builds is also a dependency of another of your vendors.
So, for instance,
in a project that has Castle.ActiveRecord as a dependency, I will have the
source for both Castle and NHibernate. I ensure NH is built first, and that the
Castle SharedLib directory for NH is updated with the build product. In
addition, if I wanted to use the newest version of log4net, but I didn't want to
compile it from source, it would be located within my
"vendors/bin/log4net/net-2.0" directory (or some such), and would be placed in
the appropriate NH and Castle directories before their respective compile
processes to ensure a consistent version of log4net across all
builds.
Of course, you have
to be really careful if you have commit access to an upstream vendor tree, and
that tree includes the shared library directory - you need to make sure you
NEVER commit the updated dependencies in the shared library directory into the
tree, for obvious reasons.
vendors.build
Description: vendors.build
6/17/2006 G. Richard Bellamy This document outlines the directory structure used for Development.
The Development directory structure should support the following requirements:
* Local Projects.
* Scratchpad, or sample source.
* Open Source (Remote) projects.
The trick here is supporting the dependencies between items! Normally, when
working with a dependency, you want to work with the pre-compiled, or binary,
version. One of the advantages of working with Open Source projects is that you
have access to the source, which allows you to trace program execution from
your local project into the source of the dependency.
To successfully trace program execution from your local project into the source
of the dependency, one must have a debug build of the Vendor/Remote Project,
and
that debug build must produce a pdb that points to a local branch of the
source.
Therefore it is prudent that any local working copy have the necessary
structure
to allow the inclusion of outside sources in such a way as to make adding
references both easy, and maintainable.
Some of the challenges can come from the various directory structure models
used by different project. Some have the Project->trunk->sub-project->src
model,
while others use the trunk->Project/Sub-Project->src model. Also, there's the
occasional project that has refactored their code repository, and you can't
access the release version of the source without downloading the
distribution...
which can also mean that the directory structure used by the release is
different then that used by the repository.
The following structure attempts to help control the inevitable slip toward
file system chaos.
Note that not all the directories are required. Some projects may not have the
need, for instance, to support a mono library set, so there would be no
\lib\mono directory.
Development
|-- [Client Name]
| `-- [Project Name]
| |-- doc
| | `--help
| |-- src
| | `-- [Sub Project Name]
| |-- tools
| | `-- scripts
| `-- vendors
| |-- bin
| | `-- [Vendor Name]
| | |-- mono-1.0
| | |-- net-1.1
| | `-- net-2.0
| |-- lib
| | |-- mono-1.0
| | |-- net-1.1
| | `-- net-2.0
| `-- src
| |-- vendors.build
| `-- [Vendor/Remote Project Name]
|-- Scratchpad
| |-- [Sample Name]
| `-- [Scratchpad Name]
`-- [Vendor/Remote Project Name]
* Local Project: The local project, whose source tree and code repository is
maintained by Crocker or Pteradigm
* Sub Project: Either VS.NET solution, or project. So you could have a master
solution file in the /src directory, and a project file in each of the
sub-project folders, or you could have a full Solution-Project hierarchy within
the sub-project.
* Vendor/Remote Project: Either an Open Source vendor drop, or the source from a
for-pay vendor library.
* Sample/Scratchpad: Downloaded samples or quick local spikes of code. This
directory will have a tendency to become quite large if rigorous pruning is not
practiced.
* vendors\bin: This is the binary distribution of a vendors product. This is
used if the vendor source is not available, or unnecessary.
* vendors.build: This NAnt buildfile is used to consolidate the build of all
the
Vendor/Remote projects. It will also be responsible for gathering all the
vendor
libs and placing them in their appropriate location ("vendors\lib\net-2.0",
etc.), if they are being generated by a build process. In addition, this
buildfile is responsible for ensuring the shared library directory of any
vendor
is properly updated.6/18/2006 G. Richard Bellamy
Repository Layout (Draft). This is based on the process used by BestPractical
(www.bestpractical.com).
- Structure -
(using sample version numbers)
/[Client Name]/[Project Name]/branches/1.0-MAINT
/[Client Name]/[Project Name]/branches/2.0-MAINT
/[Client Name]/[Project Name]/branches/3.0-RELEASE
specific versions to /[Client Name]/[Project Name]/tags/3.0.1, etc
will become /[Client Name]/[Project Name]/3.0-MAINT
/[Client Name]/[Project Name]/trunk
will become /[Client Name]/[Project Name]/branches/3.2-RELEASE
then /[Project Name]/branches/3.2-MAINT
/Vendors/[Vendor Name]/[Vendor Project Name]/current
/Vendors/[Vendor Name]/[Vendor Project Name]/[SVN Revision Number/Version]
will become /Vendors/[Vendor Name]/[Vendor Project Name]/current
- General Layout -
* trunk: The main line of development.
* branches: Various named branches of the main development line.
* tags: Various branches that are created, and perhaps destroyed, but NEVER
changed.
- Level Tags -
* trunk = TESTING: Odd minor version
o Featureset slush.
o Recommended for new development and test deployments.
* RELEASE: Even minor version number
o All bugfixes, minor features.
o NO SCHEMA CHANGES.
o Localized string changes discouraged.
o Recommended for production deployment.
* MAINT: Even minor version number; always older than the current RELEASE
o only critical bugfixes. No localized string changes unless critical.
o Not for new installations.
- Version Numbers -
When setting the version number of the Assembly:
major.minor.build.revision
When setting the tag name in the repository:
major.minor.build[Release Code]
- Release Codes -
alphaX = Pre-beta. Not code complete. Not feature complete. Compiles and runs.
betaX = Code complete. Feature complete.
rcX = Release Candidate.
-- where X = some number
See http://en.wikipedia.org/wiki/Development_stage for a more detailed
description.------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ CastleProject-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/castleproject-users
