In Maven, you should have one project/module per artifact to be produced. But that is also true that packaging type ejb3 can for example let you have only one project and two jars (client and server) be produced.
Been there, done that, got the T-shirt (a long time I wanted to place this one :D), I advice you to use the first strategy: separate client and server code. In fact, separating will have the advantage that when you're developing you can create dependencies straight-forwardly against, say, client code without risking to create deps against server code. For example, if I'm not wrong, for now Eclipse is not able to expose only some packages or source folders to other projects. Cons: you'll have to manage 2n projects instead of n inside your IDE. But, I guess that modern IDEs let us manage this kind of thing quite easily. (Other)Pros: If you're working on some specific tasks involving either client or server need, with two distinct projects you will immediately know where to work on (or where to add some specific packaging information e.g.). Because of legacy, we're still doing something quite dirty, and we are actively considering splitting. Cheers. 2008/12/29 Michael Hui <[email protected]> > Hi, > > I just want to know if there is a recommended way to layout RMI projects in > maven. > RMI projects have a remote interface that both the server and the client > need access to. > > Should I create a maven project just for the remote interface and both > client and server maven projects depend on this remote interface module? > Or is there a better way than that? > > Or should I put the server classes and the remote interfaces in one single > maven project (SR) and use the rmi goals found in the rmi plugin.. such > that > only the client maven project depends on this SR project. > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
