Hi On Sat, May 22, 2010 at 6:42 PM, Dennis Reedy <[email protected]> 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 post-integration-test. 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. HTH Patrick
