river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Closing out release 2.2.0
Date Fri, 27 Aug 2010 15:18:01 GMT
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 <dennis.reedy@gmail.com> 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.

View raw message