on 3/11/02 2:07 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote:
> Simply dividing b.p into three sections, with appropriate comments, > would be helpful. Yea, I just did this earlier today with Scarab's default.properties and I think it helped the readability of it quite a bit. > I'd further consider moving the properties in the first category, > those that structure the project and which are not really designed to > be changed without other major changes to the project, back into the > build.xml. That way, b.p would have only highly dynamic or > environment-speicific properties, and b.xml would have only structural > properties. Since the goal (I assume) was factoring out the dynamic > stuff so users don't have to edit b.xml to change the > version/environment, this seems to more explicitly follow that goal. I agree with that as well, Scarab does something similar to that. 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 would also suggest 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. -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
