On Fri, 3 Sep 2004 12:16:57 -0400, Dan Allen <[EMAIL PROTECTED]> wrote:
> I want to get some feedback on how other developers handle the
> management of certain common files across multiple project trees.
>
> I am developing about a dozen different web modules right now, each
> with its own project tree. However, certain resources are used in all
> of the projects, such as build.xml and build.properties. I would like
> to keep these files in CVS, but I don't want the files duplicated in
> every single CVS module because a change to one would still require a
> syncronization across all the projects. At the same time, I want the
> project tree to be able to stand alone so that it isn't dependent on a
> "common" folder. My question is, where do I store it and how do I get
> the most recent version?
>
> The response I most anticipate is to have a target in build.xml that
> reaches out to a common directory and pulls the newest version into
> the project tree. Then the common folder will have its own CVS module
> and all updates to such common files should occur only in the common
> folder and not on the file inside of the particular project which uses
> it. Running the target allows a project tree to be brought "up to
> date" ready for export as a standalone project tree.
>
> Am I on the money or is there a better way to handle such resources?
>
> Dan
One approach I've seen to this issue lets you have the primary
benefits of sharing common resource files like this, but also allows
limited forms of customization in a way that feels like subclassing a
Java class.
Instead of sharing the build.xml file itself, the idea is to share
subordinate build scripts that contain common targets ... say
"build-common.xml". Then, for each project that needs to share the
common targets, you'd provide a "starter" version of build.xml (as
part of a project template or something) that included the code to
pull over the build-common.xml file (in an "init" target of some
sort), and had prebuilt versions of all the targets which simply
delegate to the common version:
<target name="compile" depends="...">
<ant antfile="build-common.xml" target="compile" inheritAll="true"/>
</target>
Now, by default, individual projects are sharing all the guts of the
common tasks, but you are free to customize a little if needed ...
either by setting properties in the project's own file (the inheritAll
setting passes them on), or by inserting Ant tasks before and/or after
the call to the delegated target -- or, in rare cases, you might need
to completely replace the common target with different logic, and skip
the delegation call.
If you've ever glanced at Maven, you'll probably recognize this as the
fundamental design pattern Maven encourages - a common repository for
all the targets (although Maven calls them goals), with the ability to
decorate using preGoal and postGoal settings. You have to buy into
Maven as a whole if you want to use it, though; but it's possible to
emulate this particular concept by carefully crafted Ant build.xml
files that use delegation.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
