>There are currently three properties used in Constants.java: the name, the copyright year and the version. Ok, the first one could be simply hard-coded because it is fixed. (And I think we can remove this name property completly from the build system).
Now, if this is the only place in the java code where filters are used, I personally have no problems with hardcoding the version and the copyright in Constants.java, so that the filters are not required. This would (unfortunately) lead to the fact that we define these two pieces of information in two places and both have to be updated accordingly. But fortunately I'm currently doing the releases and I'm updating the information in the build files, so I can also update them in Constants.java as well. No problem.
What do you think?
Besides the lack of elegance and the increased complexity of making the distribution, the real problem is the 'databases' block that uses source filtering. Also the other problem is the scratchpad which has so many dependencies on libraries that we can't ship, so it would be great to tell javac to skip those files if the library is not available but without having to copy them.
Chris, how complex would be to write new <javac> ant task using your JavacAPI and the eclipse compiler? I think it could even speed up our compilation times and memory usage.
Anybody else has ideas on how to solve this issue?
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
