Andrew May wrote: > Not having developed for Ant before, and not being that familiar with > the coding conventions used I could use some advice in how to proceed.
See http://jakarta.apache.org/site/source.html for starters; you will be most interested in the "Patches" section. As for the coding conventions, Turbine has explicitly defined their standards at http://jakarta.apache.org/turbine/code-standards.html , while in general we haven't. The rule of thumb is, follow the standard in the existing file because it is *really* irritating to see style changes in the same file. The only hard and fast rules are: 1. No tabs, only spaces. 2. 4 spaces per "tab". You know, looking at Turbine's conventions, I have to admit I like them. Do the committer's have any strong feelings about adopting a consistent standard? Or more accurately, stating what our defacto standard is? > 1) Extend the existing Pvcs task to have a "command" argument, which > could be "Get", "Version", "Promote" etc. This would make it a bit like > the CVS task, but has the problem that some arguments would not make > sense for a particular command. It also might get a bit messy! > > 2) Create PvcsGet, PvcsVersion, PvcsPromote tasks and deprecate Pvcs > task. Split out the common functionality which is mostly in getting the > list of files from the repository using the plci command (Pcli.java?), > and then just have the appropriate arguments for each task (although a > lot of these would be common). > > 3) Keep the Pvcs task with the common arguments and have nested elements > for the different commands. This would probably be more difficult to > write :), and in reality it would be a bit like 2) with the Pvcs task > doing the list of files and the command elements (with a PvcsCommand > interface or something) doing the get/version/promote. I'm concerned > that the structure of the tags would be reflecting the underlying PVCS > commands, and also that this might not support tasks for individual > files very well. > > Personally I favour 2). As do I, so I'd encourage you down that path. > I would also like to incorporate any fixes/improvements suggested to > what's already there, and add more arguments to support more of the > command line options (like quiet output). Submit patches, and hopefully someone will have time to check them out. Glenn McAllister SOMA Networks, Inc.
