Strategies for dealing with circular references between two modules

["Karr, David" <da...@attws.com>]

This is sort of an "ant" question, and sort of an "ejb" question, but sort of not either.  It's a build problem related to EJB/JMS.

I have a situation where I have two module directories in an application, where one module is a JMS client of the other, and they reverse roles for EJB calls (read messages for work to do, but send back results as EJB calls).  The actual client JMS interface is somewhat complex, and with details that are specific to the server.  Therefore, I thought it would be logical to have the actual client interface code be "owned" by the server module, sort of how JINI owns client interfaces.  In my JMS usage, I'm using "object messages", where I serialize an object to send, and unpack it on the server end.  By containing the actual client interface in the server module, other module directories don't even need to know about the serialized object.

I like the architectural aspects of this, but this causes a wrinkle at build time.  By doing this, I've set up a circular reference between these two module directories, so neither can be built first.  I can see two ways to resolve this.  I initially thought of the first way, but a colleague thought of the other way, and I'd like to get some external input from other people on these ideas.

One way is to have two build targets in the server module, one for building the client code and one for building the server code.  Using this, we would first build the "client" part of the server, then the real client, then the server.  It's a good idea to make sure your server code is segmented from your client interface to facilitate the "exclude" and "include" tasks (this is a good idea anyway).

The other strategy is completely different.  It avoids having to build the server directory in two steps.  It does this by setting the "srcdir" attribute of the "javac" task to include not only the source of the server directory, but also the source of the other directory.  Used in this way, we build the "server" first, and it's able to compile it's EJB references because it can see the EJB source.  We then build the "client", which compiles because the client interface has already been compiled.  One drawback of this solution is that you end up with the actual client source being compiled in two places (and class files being stored in two different "build" trees).  We already have to use "include" to make sure we get just the server code, but we'll also have to make sure we don't accidently include the client class files (pretty easy).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>