> Although, I'm not entirely 100% sure which properties belong in build.xml > and which don't. I can see a property such as dist.dir and packages= going > back into the build.xml because in reality, they don't need to be changed by > the user, but others are definitely questionable.
I could see dist.dir and packages (call this javadoc.packages, since I could see wanting to filter on packages in other ways) going into the build.properties, since they are really modifiers as to how you want the distribution built. I could also see build.root going in b.properties, which would enable (for example) the source tree to live on a read-only or shared volume. Other build.x properties go in b.xml. I'd propose these rules: - anything having to do with the structure of the source tree goes in b.xml - anything having to do with the structure of the build tree goes in b.xml - anything having to do with resources that comes from outside the source tree, or the locations of where to put the build or distribution trees go in b.props. - Anything having to do with anticipated build options (build only this subset of the distribution) should be controlled by flags in b.props. > modifying the javacc.* properties to be a single property... > the location of the JavaCC.zip file (relative or absolute). There is > really no need to have three properties like that. Right. Besides, the structure of the JavaCC distribution directory changed at one point, so with the three-property case, you'd still have to change two properties anyway. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
