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.
