river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: River archetype
Date Sat, 22 May 2010 20:01:38 GMT

On Sat, May 22, 2010 at 6:42 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> I'd like to solicit some ideas into what would be the source and configuration content
so a River archetype [1] can be created. This will allow developers to create a working River

Great idea.

> Generate a simple service that just provides an empty interface, service impl and configuration?

I would aim for multiple archetypes. I think there are some things
that can be re-used across archetypes, for example, the dependency
lists. There should be at least one archetype which creates a working
end-to-end application, even if it's HelloWorld, perhaps a thin-proxy
and a smart-proxy version. People who are completely new to River can
then just add methods, restart the app, and see the changes. People
who are already comfortable with River can use the "empty project
stub" archetype. I think with parent POMs you could pull out the
common pieces and so setting up new archetypes would not be difficult.

> For configuration, use the Jini configuration approach or can we move forward with adopting
the Groovy configuration provider?

I myself never warmed up to the Jini configuration system and feel the
communities I follow want lightweight approaches with low learning
curves. I haven't used the Groovy configuration yet but I think it's
worth a try.

Personally, I would also vote for including a Mayflower/Spring-based
configuration as Spring is pretty well established in its markets and
using it could prove more inviting for teams already using Spring.

> Generate a JavaSpace project?

I think at a minimum having the dependencies available via Maven would
be useful.

> Should the Rio classdepandjar mojo be used to build the artifacts? In this way we can
produce the service, dl and api artifacts right out of the gate.

Sounds great.

> What to provide for testing the application? Does the River test framework make sense
to include?

In our team we use Maven sub-modules to organize our services,
including a module "CLI" in most cases. The CLI module includes
classes meant to be run from the command line, to contact and
communicate with the service. A lot of the uninteresting work (lookup
and discovery) can be pushed into helper classes, so the CLI apps are
mostly focused on service invocation. We don't actually ship the CLI
modules; they are used during development for testing the service once
it's far enough along. So the archetype could generate a small CLI
that performed L&D, then called a method on the service.

We also write unit tests within the module source itself, and
integration tests which run against running services. The integration
tests in this case are still written as jUnit tests, but perform
lookup and communicate with the running services. I don't know if
anything special needs to be done here. If you can get service
launching to take place within the POM (for example, in the
pre-integration-test phase), then you could launch unit tests that
communicate with those services, and the shutdown in

I remember I tried using Chris' Maven work about a year ago, when I
was playing around developing a Jini-based open source project. I
remember I couldn't get launching to work correctly, and at the time
didn't want to spend time digging into his code, so wrote shell
scripts to launch and shutdown. I think if we can get it to work,
having a Maven plugin properly start the standard services (Reggie at
the very least) would be a plus.

As for organization, we have our Jini services organized within their
own directory, where the top-level POM is the parent POM for the
service (itself inheriting from a project-level POM), and the
sub-modules inherit from the module POM. By default we require an
interfaces/ and service/ directory, where the interface includes the
APIs used by clients, and the service module declares interfaces as a
dependency. In most modules there is a cli/ module as well, as
described above. We've found this to be a fairly straightforward
service module layout. From within all the major IDEs you can open
either the top-level POM, and get all modules imported automatically,
or open any sub-module POM directly.


View raw message