Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 54321 invoked from network); 8 Sep 2002 03:07:04 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Sep 2002 03:07:04 -0000 Received: (qmail 9329 invoked by uid 97); 8 Sep 2002 03:07:43 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 9296 invoked by uid 97); 8 Sep 2002 03:07:42 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 9284 invoked by uid 98); 8 Sep 2002 03:07:42 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <002501c256e4$d0410710$31b0e40f@nevis> From: "Steve Loughran" To: "Ant Developers List" References: Subject: Re: preprocessing java source Date: Sat, 7 Sep 2002 20:07:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ooh, this would work as way of having conditional assert statements in code designed for 1.3 and 1.4. This would make an interesting little addition to the optional set, if nobody has objections. It would of course need to be built against 1.6alpha, tab-to-spaced, commented, etc; the usual housekeeping work. thoughts? ----- Original Message ----- From: "didge" To: Sent: Friday, September 06, 2002 17:05 Subject: preprocessing java source > Folks, > > For some time I've been looking around for a solution to the problem of > handling multiple JDK platforms. In C/C++, I would have relied on the > preprocessor and it would be a done deal. No such luck in Java. > > However, I realized that by combining Ant and Velocity, I could come up with > a workaround that might meet my needs. I'm offering my solution to the this > group for possible inclusion as an optional ant task, if you feel that it is > generally useful as I think that it is. > > Essentially, I subclassed the Javac ant task, and used Velocity to > preprocess each file as if they were template files. Then, I let Javac > continue to compile just the preprocessed files. > > The net effect is that source files become Velocity templates and you can > now use VTL to do as you please with your source. And, as an added bonus, > the VTL in the source files can access all of the properties known by Ant. > I simply put the Project.properties into the VelocityContext supplied to the > merge(). For example, you can get access to an ant property called foo by > using this VTL: > #if ( $ant.get("jdk.target").startsWith("1.4") ) > some code... > #else ( $ant.get("jdk.target").startsWith("1.3") ) > other code > #else > default code > #end > > It is also possible to comment out the preprocessor directives so that IDEs > won't choke on the VTL directives. Since Velocity ignores Java comments, > Velocity will process its directives regardless, but this can result in some > rather wierd situations for IDEs, as you can imagine, since you could end up > with a strange mix of code. Non realtime parsing IDEs probably won't care > but those that do, such as IDEA, will markup the code with lots of syntax > errors. But this should work very well at least for assert like statements. > > On the bummer side, you must use ant to build effectively. This is > mitigated a bit by the fact that most IDEs now let you execute your ant > targets directly, but you have to be smart about debugging. You can no > longer debug against the original source, you now have to go against the > source in the temporary directory, unless your java-commented VTL is very > carefully written. > > An additional bummer is for javadoc comments that reference set methods. > They usually look like someclass#setFoo, which Velocity interprets as a > directive. But by simply escaping the #, e.g. someclass\#setFoo, all will > be well. > > > I've successfully used this now to write a complete java.sql wrapper library > that compiles from version 1.1.x through 1.4.x from a single source. > > I'd be interested to know whay you think, if any of you have any time to > look at it. See the attached .zip. > > To build, you'll need to copy ant.jar (1.4.1 is what I used) and > velocity-dep-1.3.1-rc2.jar. (I didn't include them with the zip because > they're large and you may not want to bother). Unzip the .zip and copy the > aforementioned .jars into the lib directory and exectue 'ant build-g'. To > see an example, execute 'ant ppjavac' which will preprocess and compile a > file under the example directory called PPTest.java. You'll get a > sub-directory called 'foo' where the processed file will end up. It's > .class will go into build/classes. > > The interesting ant target in the build.xml is called ppjavac. It takes all > of javac's attributes and adds two more. preprocess allows you to turn on > or off preprocessing. prepDir is the location of the temporary directory. > > enjoy! > > didge > > ---------------------------------------------------------------------------- ---- > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: