[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [jdt-apt-dev] unit test for annotation processors?
- From: "Walter Harley" <wharley@xxxxxxx>
- Date: Wed, 12 Jul 2006 08:39:44 -0700
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcaluQmDsnogvBPPTUemeZ6X0xC3YwADrOkg
- Thread-topic: [jdt-apt-dev] unit test for annotation processors?
You could take a look at the org.eclipse.jdt.apt.tests
plug-in, which is how we unit-test APT; not quite the same, but might give you
reason that an APE needs a JavaProject is that we rely on the JDT compiler, and
JDT doesn't know how to compile a file outside of the context of a
project. (Unsurprising given that compilation requires knowing project
attributes like the classpath.) Keep in mind that the APT interfaces allow
you to navigate the entire typesystem, not just one file; so other files in
the project have to at least be reachable on request. If you look at the
apt.tests plug-in you'll see that in general it has to create a new project, and
then create a new java file inside of it, to test
said, I totally agree that some better test hooks would make life easier.
We'd certainly be receptive to suggestions (and patches!).
JDT APT team
Does anyone have any suggestions for unit testing
annotation processors? At a high level, an ideal situation would be if there was
a factory method for AnnotationProcessorEnvironment objects which took a Java
source file as input (perhaps as a String containing source code, or more
conveniently a reference to a file). The APE instance could then be passed into
the constructor of the annotation processor and the process method called. The
behaviour could then be measured by obtaining the Messager instance from the APE
and interrogating it for the expected set of errors.
I couldn't see an obvious factory method of that sort, so
I tried a few ideas using Proxies, reflection, subclasses etc. Unfortunately,
the design of BaseProcessorEnv seems to make this quite difficult. The
constructor calls AptPlugin.getAptProject(javaProj); which makes it difficult to create an instance to delegate calls to
without having a valid IJavaProject.
Anybody been down this road already and have some pointers?
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.