DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20867>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20867 The possibility of getting properties from ant scripts [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2003-06-20 19:57 ------- Uhm, I let myself to reopen this rfi, since after my enthusiasm on your solution I shortly find out, that it still doesn't resolve all my problems. But let's get to the point. It is great thing, that the loaded properties are parsed against ${var} references. It really is very helpfull, but still I can not get rid of redundant code. Similary to what you'd suggested in the link you have provided last time, I've defined lib.properties, prj.properties (common properties for most projects) and commons.xml (common tasks for most projects). All those files are placed in .ant directory available to all build scripts. Besides I have build.xml and build.properties in each project's ant folder. File build.properties holds release, version, revision numbers, compiler options, some per-projects settings, etc. File commons.xml contains (amongs others) three targets: release, version and revision, which are called in init target of the commons.xml, which of course is called from each build.xml/init target. These targets utilize <propertyfile/> task to eventually set new version numbers, depending on build mode passed via -D property. This works fine. The point is, that now I have to 1) put version numbers (or shall I say: version string) into lib.properties and 2) replace it every time I change version number of some of my projects. Besides it's redundant. Well, I could work this around, and place in lib.properties file just the path to the project dir (some libs are "external"---provided by other people/companies, and some are "internal"---provided by me and their sources are somewhere in my fs) and read the build.properties for needed subproject (lib) in each build.xml and set necessary strings, but I have to do it in each build file--- the code is exactly the same and from the point of view of a programmer it's terrible solution. What shall be done, then? Well, it would be great to add more processing power to properties files or (that's what I would vote for) have the possibility to include properties (and eventually all refs) to build files. With this I could change lib.properties into lib.xml and set there complete <path/> or <fileset/>---in most cases it's common for most of the projects, I could set there some filterset, properties a.s.o. I have prj.properties skelton like this (just two properties to make it more clear): ... prj.tag = ${prj.name}-${release}.${version}.${revision} prj.jar = ${prj.tag}.jar ... This file is placed in shared folder (let's call it .ant). Version numbers of each project are placed in build.properties, eg: ... release = 1 version = 3 revision = 43 ... To set default properties in each build file I have to: <property file="build.properties"/> <property file="${.ant}/prj.properties"/> and that's okay. Worse if I need to use subproject and to know this subproject version numbers. I can ofcourse do <property file="${subprj.path}/ant/build.properties" prefix="${subprj.name}"/> but I can not make use of ${subprj.name}.prj.tag and -.jar like I did in the main build file. I think of some kind of task like this: <include prefix="${subprj.name}"> <filelist dir="${subprj.path}/ant" files="build.properties"/> <filelist dir="${.ant}" files="prj.properties"/> </include> I think that <include/> element (or whatever would it be called) could make use of inheritAll and -Refs attrs too. By default all inherit attrs should be set to false IMO. Further, we could include not only props and refs, but also targets---in this case the immutability rule should apply too. (It should be discussed if targets are to be prefixed also---maybe we could add a switch prefixTargets="true|false" for that reason). The prefix atribute is optional and the sequence of <filelist/> elements and files named in files attribute must be preserved. Maybe, for shortening, an attribute files (and optionally dir?) could appear in DTD for <include/> element too. The ability to include props, refs and targets into build scripts would greately reduce the amount of code in each script and thus the nescessity of updating of tones of files when something changes. Well, I am not sure if I am completly understandable with my explenation--- English is not my native language, besides I am writting it as I am thinking of it, so I do not have precise vision of including build scripts. But I hope in general it's obvious what I think of---thank you for your time. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
