xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Pogue <mpo...@apache.org>
Subject Re: [Proposal] Guidlines for package distribution of Java projects: like XML file being read by class
Date Tue, 23 Nov 1999 16:59:02 GMT
Shane_Curcuru@lotus.com wrote:

> -- I really like Thomas' idea below, where the actual version info is
> stored in an XML file, and then read in by a Version.class.  As he points
> out, both communities are happy: XML and text parsers have the info, and
> Java programs have the info.  This would also make it simple to have the
> version info in just one place for the entire project, since the
> documentation could also parse the XML file and pull out version info too.
> One important question is where should the XML version file live, both in
> source trees and in binary outputs?  Although the Version.class can
> gracefully fail when it doesn't find the version.xml (or whatever name)
> file, I'd rather that this didn't happen too often.

I'd be against a separate XML file, requiring an extra Java or C++
program to read it (to parse it, and pass it into the doc builder or
general build script).  It just makes the whole build process more
fragile (one example: we shouldn't require a working XML parser, in
order to build the XML parser package itself).

It's also an installation problem, since it requires carrying the XML
file into the final package, if the version can be read at runtime
(which I think is a requirement).
And, remember that we need to make this work consistently for both Java
and C++, too (this isn't just a Java problem). 

I'd much prefer to stick with something much simpler, e.g. hard-coded
version numbers in Version.java and Version.hpp, and a second hard coded
version number in (or passed into) the build script.  It's simple,
usable at runtime and build time, and doesn't have the installation or
build problems I mentioned above.  One disadvantage:  the version number
exists in two places at once, so there is potential for a version
mismatch problem, if somebody changes it in one place, but not the

Another possibility -- keep it in the build script ONLY, and dynamically
modify Version.java and Version.hpp to use the correct version number. 
This solves one problem (potential mismatch), but makes the build more
complicated (requires a sed, or similar, step).


View raw message