It looks like you're looking for an archtetype, but I don't even know if there is such a thing as a multi-module archtetype!
On Fri, Aug 27, 2010 at 11:13 AM, Dennis Reedy <[email protected]> wrote: > > On Aug 26, 2010, at 725PM, Peter Firmstone wrote: > >> Yes, thanks Dennis, that's what I was trying to say ;) >> >> Seeing as we've touched on Maven again, is anyone with some Maven experience >> able to help out with an implementation of Maven Provisioning of proxy jar >> artifacts. Seeing as everyone is starting to do this I'd like to see a >> standard way adopted. The proxy jar's can themselves depend on other Jar's >> since maven can provision those. By provisioning artefacts, it reduces the >> risk of denial of service. > > I dont think we should be concerned about this right now, furthermore, this > is generally out of scope [1] for what I think River should be focusing on > now, and for the foreseeable future. > > What would be more helpful is conventions on how developers that use River > and Maven should create their projects. We have had discussions on this in > the past (so this is mostly a review), I hope that we can agree on the > conventions, document them and eventually create a River archetype that > generates a default project structure that produces the requisite artifacts. > > We had started out using a Maven-ized classdepandjar > (http://www.rio-project.org/classdepandjar-mojo.html), allowing the creation > of multiple artifacts from a single project (service.jar, service-dl.jar, > service-ui.jar, etc....). While this worked, the pom became overly > complicated, the approach became confusing, especially if one of the > artifacts had dependencies that the others didnt. > > What we have moved to (and I think this is common across other developers) is > to create a multi-module project that reflects the basic architectural > elements of a River service. Basically, a River service is composed of the > following modules: > > some-service\ > api\ > *proxy\ > *ui\ > service\ > > * = optional > > The api module contains all the classes (interfaces and other classes) that > is needed to communicate with the service > The proxy module (optional), depends on the api module, and provides smart > proxy support > The ui module (optional), depends on the api module and provides support for > a service user interface > The service module, depends on the api module (or proxy module if used) > provides the backend service implementation. > > Using this approach produces an easy to use and understandable model, doesnt > require classdepandjar, and dependency management is handled quite cleanly. > Some will argue on the names of the modules, it doesnt really matter what the > names are, as long as the project has its constituent elements broken out. > > Maven groupId and artifactId conventions we adopted are as follows: > > com.foo:some-service:version > com.foo.some-service:api:version > com.foo.some-service:proxy:version > com.foo.some-service:ui:version > com.foo.some-service:service:version > > Additionally, if I wanted to use a service (as a client) I would declare a > dependency on com.foo.some-service:api:version > > I hope this helps, and I do think if we can agree on conventions like this, > document them, and produce a simple example that uses them, it will help > developers use River and Maven. > > Dennis > > [1] Higher level frameworks like Rio have this capability. > >
