river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Closing out release 2.2.0
Date Fri, 27 Aug 2010 22:48:07 GMT
Dennis Reedy 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
> 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. 

Can you add this (edit) to the document at

Got any advise on how to handle message digests?


View raw message