ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Lyon" <m...@stargus.com>
Subject Automated source config model?
Date Fri, 30 Aug 2002 14:45:23 GMT
Hi,

I recently migrated our shop from VSS to CVS. We currently have two projects that exist on
branches in our CVS repository and share a common platform code base which exists on the main
code line. I have been tasked with investigating and implementing a solution for allowing
developers to specify on a package-by-package (and perhaps an even more granular file-by-file)
basis what branch to grab files off of to build.

We have debated ad infinitum the notion of modularizing and productizing, but we would have
to refactor our source layout (possibly including package structure and dependencies), and
deployment and packaging models to support modularity. This does not seem feasible at this
point in time, given the deadline pressure for deliverables on both projects. Our current
model would allow us to maintain source commonality at the product platform level while placing
divergent or new code on project branches that could be merged into the mainline at regularly
scheduled intervals for releases. 

However, our developers don't feel like they have the support they need from an SCM or build
perspective to proceed. They want to be able to configure the source pool in an automated
fashion to support their efforts, so that with a single command, they can fetch (for example)
V1.1 of the platform code, V1.3 of the UI code, V1.7 of the content code, layer on their own
project branch code, have all of the sticky bits set correctly in their working directory,
and create the builds they need to drive their development efforts. A reasonable requirement,
I would concede.

One suggestion on how to overcome this challenge is the implementation of a ClearCase model
of using configs to drive the build process at our shop. Simply put, an external properties
file or script would be implemented that could be invoked by Ant to fetch, as an example,
V1.1 of com/foo/*, V1.2 off of com/fubar/**, com/stuff/MyFile.java off of MyProjectBranch,
and com/stuff/TheOtherGuysFile.java off the main code line for a build. The idea is that this
separate external script or properties file could be maintained by developers on their project
branch so that they could specify how to set the sticky bits for their fetch of ${src} to
get the build they need. This file would also provide developers with an easy way to maintain
visibility into the components that create their build.

I'm curious as to how others have faced this challenge using Ant and CVS in a production build
environment. One thought I had was to investigate using the Ant-Contrib <foreach> task
to iterate over a 'src.properties' file that would contain the ingredients, so to speak, that
are passed to a fetch target (e.g a <cvs> task that would read in the 'src.properties'
file and grab the correct revisions of every file needed to build the product for a specific
developers' build case). Another idea I had was to simply create external .sh/.bat/.cmd scripts
that could drive retrieval of source code and be invoked from Ant via an <exec> task.
It's not really going to be scalable to put hacked build.xml's on every branch that have 1.000
line-long fetch targets that set all the sticky bits correctly; we need a more flexible and
extensible approach.

Thoughts?

Matt


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message