Stefano Mazzocchi wrote: > > Carsten Ziegeler wrote: > > 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. > Ok, we should not mix the problems here - one is filtering and the other one deals with libraries. I currently see now solution for the databases block. Has anyone else a good suggestion here? I really don't have thought about it, but would it help to split the source directory of the block into three sections (common, jdk1.3 compliant, jdk1.4 compliant) and the ant script only selects the correct directories for the sources (either common and jdk1.3 or common and jdk1.4). Does this make sense?
Carsten
