Hi Baptiste, Thanks for the reply. I think I was just stuck in a philosophical question. Because for me in order to make something an artifact I ask the question "what is an artifact"? Just by looking at how it's defined, i see it has coordinates ( a name) , version , packaging and dependencies.
Does an artifact with just the remote interface actually deserve to be in it's own module? -It isn't executable code (for one thing) -It has a version (it should, but shouldn't the versioning be determined by the service writer, kind of?) The client implementor would need to decide which version of the interface module to depend on, but then, what version of the server does the client depend on? The client should know to some extent, and how would he define that dependency in maven? But for this argument I think it can be argued that the server artifact version doesn't matter, because it must conform to whatever version of the interface module it depends on. The only problem is during the maven build process, I guess, because you will not know which version of the server module to build, just by looking at the pom file. Thanks, On Mon, Dec 29, 2008 at 12:59 PM, Baptiste MATHUS <[email protected]> wrote: > 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 ! > -- Thanks,
