It makes sense, but it seems a bit ugly. I guess there's nothing to stop the two projects sharing the same Java package namespace. Hmmm.
OK, I guess I'll go with that. It seems like Maven is being a bit intrusive, though. On the other hand, I guess it will drive home to everyone the distinction between the two. Thanks, Andrew Allison, Bob wrote: > The normal way of handling this kind of dependency tree is to put the > common stuff (each service's interface and DTOs) is a separate project. > Then each service's project depends on this common stuff project. > > Make sense? > > -----Original Message----- > From: andrew cooke [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 14, 2006 09:14 > To: [email protected] > Subject: (Strictly limited) circular dependencies with M2 > > > Hi, > > I have been asked to configure Maven 2 for our new project at work. The > project architecture is a set of services, each of which will be a > separate sub-project in Maven 2. > > However, each service depends on the *external interfaces* of the > services > it connects to. > > I know that generally circular dependencies are a "bad thing", so I want > to explain carefully why the dependency we have is not: > > Each service has a contract that it implements. A calling (dependent) > service depends on this contract. If the contract is broken, the > system > will fail. > > Since the contract is critical, it makes sense to test it as early as > possible. Preferably at compile time. We can do this (to a limited > extent) by expressing the contract as an interface. So any code that > uses service X compiles againts the interface that X provides. > > We can then insert proxies and messaging so that the services can exist > on different machines, etc. More details at > http://www.acooke.org/cute/MuleJavaIn0.html > > Of course, we do not want "deep" dependencies of one service on another, > so the external interfaces are restricted to: > > - Java interfaces that the service implements > - Data transfer objects (serializable, simple beans) > > How should this be structured? Since the data transfer objects are > shared > between services and have some additional constraints from the messaging > technology (serializable; it would also be useful to have a carefully > designed inheritance hierarchy for simplifying routing decisions based > on > class) I think they should go into a separate "messaging" project. The > interfaces that each service provides, however, belong in the > appropriate > service. > > So we have the package structure: > > project > +- messaging > | +- data transfer objects > +- service 1 > | +- external interface > | +- implementation > +- service 2 > . +- external interface > . +- implementation > +... > > To build this I need to: > > - compile messaging (data transfer objects) > - compile external interfaces for each service > - package external interfaces and message objects > (necessary for the messaging system) > - compile implementations for each service > - package each service (both interface and implementation) > > (I may also need to package services as ejb3 beans) > > If I do this, all dependencies are resolved correctly. > > My question, then, is how do I do this with Maven 2? Sorry I had to > write > so much to ask it, and further apopolgies if this is really obvious. > I've > looked around the documentation, but can't see how this level of control > is provided. > > Thanks, > Andrew > > -- > ` __ _ __ ___ ___| |_____ personal site: http://www.acooke.org/andrew > / _` / _/ _ \/ _ \ / / -_) blog: http://www.acooke.org/cute > \__,_\__\___/\___/_\_\___| aim: acookeorg; skype: andrew-cooke > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
