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? Carsten > -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 22, 2003 12:53 PM > To: Apache Ant > Cc: [EMAIL PROTECTED] > Subject: Javac task design problems > > > Let me give you some context: Cocoon has one of the most complex builds. > Our entire build files reached 250Kb. Half of which were dynamically > generated thru an XSLT transformation (for those optional modules we > call "blocks"). > > The build system was simply too complex to be maintained and I decided > to redesign it. > > Build time went from 25 minutes to 5 minutes on my machine (a pentium II > 366 ronzputer). Other people experienced equivalent speedups and > everybody is joyful, singing and dancing and with renewed faith > on mankind. > > Now, during refactoring, people started to question the need for copying > files in the build dirs when only a few required filtering because not > only the process uses time and disk space but because... > > > you copy a source code filename from a stack trace, open the file, > > correct the bug and you're happy. Except you've been working on > the copy > > from the build subdir, and on the next build your changes are gone. > > I think almost all cocoon developers experienced the pain of this, so I > decided to design a 'copy-free' design. Unfortunately, I found out that > it's not so simple. And it's probably my fault! > > Let me remember you that I'm the one responsible for the introduction of > the <filter> task and subsystem in Ant. The design pattern was: > > 1) prepare the build by copying the source files (so that filter acts) > 2) compile the filtered version > > I was perfectly aware of the fact that this doubled the use of disk > space, but disk space is not that big of a problem nowadays so I decided > not to care (and nobody complained). > > But the 'lost-update' issue is a much more serious one. Dead serious, I > might say, the problem is that the way the javac task is designed > (again, it could well be my fault since I enhanced that task a lot in > the past) is that is path based. > > Now, suppose that you have a codebase with 580 java files, but only one > of them "Constants.java" requires filtering (for stuff like @version@ > and @year@). > > The ideal solution to the problem (without requiring to filter > everything out would be) > > <copy todir="${build.src}" filtering="on"> > <fileset dir="${src}"> > <include name="**/Constants.java"/> > </fileset> > </copy> > > <javac destdir="${build.dest}"> > <src> > <fileset dir="${src}"> > <exclude name="**/Constants.java"/> > </fileset> > <path location="${build.src}"/> > </src> > </javac> > > too bad it doesn't work because the <javac> tasks assumes that each file > in its fileset is a directory! > > Now: did I overlook something or javac has to be modified to allow this > to happen? > > [please, keep me CC-ed since I'm not subscribed to ant-dev. Thank you] > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > Pluralitas non est ponenda sine necessitate [William of Ockham] > -------------------------------------------------------------------- > >
