FW: Building Controls when Checkers are involved

[Zachary Smith <zs...@bea.com>]

Hey,

I'm working through some controls build issues and wanted to run some
things past the list.

I have been groveling my way through the controls/test build process and
trying to make some sense of it.  There are a series of slightly
confusing parts to this process and I'm trying to grok how we're going
to explain this to our users so that a) they can begin building useful
controls projects and b) migrate those projects to other build systems
(ie, their IDE of choice, larger projects, etc).

The controls build are in a multi-phase process and that appears to be
inevitable for reasons I'll try to highlight.  The purpose of this email
is not so much to dig into controls build requirements but more to get a
discussion going on how to structure controls projects to be flexible
for migration and hopefully straight forward to the end user (ie,
controls developers).

Using the current test controls code as an example I'll explain how I
understand the current controls build requirements.  

1. The first thing that must be compiled is the Checker code.  Control
interfaces (@ControlInterface) which set a 'checker' will need those
checker classes available *before* apt processes the .jcs and .jcx files
and generates (and optionally compiles) bean code.

2. Next, bean code must be generated from .jcs and .jcx files and then
compiled.  This stage may require the existence of a checker.class as
mentioned above.

3. Assuming success on the above two steps the client code can now be
compiled and developers everywhere may rejoice.  Yaay!

This all seems fairly straight forward to me until I begin to think
about project organization when Checkers are involved.  A fairly common
use case I see for a checker is to have the following project structure:

src/
    foo/bar/mycontrol/
       FooImpl.jcs
       Foo.java
       FooChecker.java

It would also not be uncommon to have FooChecker reference annotations
and fields in Foo.java (in fact, one could argue it wouldn't really make
sense if it didn't in most cases...)

The question I have here is now how do I build this thing easily?
Without using heuristics to point a build tool at the src/ dir and say
"build everything with *Checker.java" first, I'm in a bit of bind.  And
if I do rely on heuristics in my custom build system what now happens if
I wish to move my code into the build/project management of my favorite
IDE?  

Another option would be to separate my project like this:

src/
    controls/foo/bar/mycontrol/
        FooImpl.jcs
        Foo.java
    checkers/foo/bar/mycontrols/
        FooChecker.java

I can then point a build tool at src/checkers but referencing fields in
Foo.java from FooChecker doesn't work so the usefulness of my checker is
really in question here ;)

So, to reiterate my question, how can I structure a controls project in
such a way as to easily migrate to other build systems?  Many developers
have grown accustomed to importing some src into their IDE in a
"project" type thing, telling the IDE build system what the class path
is, and pushing "build" and letting the build system figure out the
rest.  It would be great if that user experience could be possible with
controls.

Thoughts?

#!/zach

P.S. I am working through this problem is real life - this is not an "in
a vacuum" question so I'd be glad to try others ideas out!