The interface which I had defined in Java was not meant to be a buffer interface, it was a generic DomainObject interface used to enforce certain implementation constraints on the domain objects (required equals(), hashCode(), getId(), setId(), getVersion(), setVersion(), etc). It might just as easily have been an abstract base class. Sorry for the confusion

I think that the Eclipse compiler is a better candidate than javac, as the latter seems to support only file based sources.

I’m confused by this post. You mention:

The Java domain object which I converted to Groovy implemented an interface defined in Java, and the domain object itself was obviously used throughout the application, implemented in Java.

That is actually the solution to the chicken and egg problem. In other words if you use an interface as a buffer between Groovy and Java as explained in Deirk’s book then compilation can proceed as normal. The only time that falls apart is if your Java references concrete implementations along with the interfaces (bad practice) or if the interface itself is defined in Groovy (not really necessary). Of course there are those situations where you’ll want to co-mingle the two languages where Java calls Groovy calls Java, or Groovy calls Java calls Groovy. That’s where formal Maven2 build phases fall apart a little. Using interfaces would suggest some degree of separation but it is not always desirable to host separate projects for simple operations. It’s an issue that won’t be solved in the short term, not until javac becomes Language aware or groovyc becomes Java aware (hint, hint, to the Groovy team). I’m just babbling, let me get back to my day job.