[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-dev] [how to?] Preprocess .java files before they are passes to the JDT compiler
|
Hi all,
I was wondering if anyone has any tips or pointers on the following
problem. (Is this the right mailing list?)
I am writing an Eclipse plugin that needs to "preprocess" .java files
before they are compiled by the JDT builder.
As an example of why someone would want to do this, take the iContract tool
( http://www.reliable-systems.com/tools/iContract/iContract.htm ). It
preprocesses .java files, looks at special javadoc comments, and inserts
pre/post conditions into your code. There also seems to be a VisualAge for
Java plugin for iContact ( http://www.reliable-
systems.com/tools/iContract/IDEs/VAJ/VAJ.htm ).
So, I am wanting to do a similar thing in Eclipse (not an iContract plugin,
something else).
In an ideal world, this would be easy if you could install a "builder
plugin", that was passed an InputStream for each .java file, and returned
an InputStream that represented the processed .java file. That would be my
*ideal* mechanism, but I know it doesn't work that way in JDT.
I have partial implementations of the following two techniques I'm trying.
But before I work on them some more, I was wondering if anyone has any
recomendations. Or is the current JDT builder not really designed to
support this.
Preprocess trick 1:
a) Install a custom Builder as the first builder in the project.
b) It's job is to pre-process the .java files, and copy them to some
temporary source directories.
c) These source directories are added as source-paths to the IJavaProject.
d) The "real" source directories are hidden (I'm just setting a very
liberal "exclude" at the moment).
e) The JDT builder picks up my .java files before the "real" .java files,
and compiles the preprocessed versions instead.
This solution is clunky... you have these temporary source files appearing
in your project, etc.
Preprocess trick 2:
a) "swizzel" all the "source" IClassPathEntry objects in the project (while
the JDT builder is running)
This involves removing the existing IClassPathEntry objects, and replacing
them with my own subclass of IClassPathEntry. My subclass delegates to the
existing objects, but does a little "path munging" to point to the real
entries.
This trick actually isn't working too well. In addition, it is documented
that clients shouldn't subclass IClassPathEntry themselves (since all the
elementEncode/Decode stuff in the ClasspathEntry concrete subclass is kinda
important ;D )
So, any ideas? My other solution is to cut-and-paste
org.eclipse.jdt.internal.core.builder.JavaBuilder into my own builder, and
implement the filtering directly (I would probably then have a different
cut-and-pasted builder for each version of Eclipse... yuck).
Thanks for your time,
=Matt