On May 22, 2010, at 401PM, Patrick Wright wrote: > 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,
Lets start with HelloWorld, then we can build from there. > 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. I have submitted the GroovyConfiguration provider to the jira issue, it would need to be added to the project. The other option is to include the Rio artifact that provides this support. > > 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. Thats fine, I would need help in figuring out what that is though. FWIW, Rio provides its own archetype (http://www.rio-project.org/rio-archetype.html), and also provides Spring support as well. Maybe we should do a Rio/Mayflower combo :) > >> Generate a JavaSpace project? > > I think at a minimum having the dependencies available via Maven would > be useful. FWIW, I do have these artifacts in Rio's repo as com.sun.jini:outrigger:2.1 and com.sun.jini:outrigger:dl:2.1 > >> 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. Ideally using River's test harness would work. I have written a JUnit test harness that is a custom extension of org.junit.runners.BlockJUnit4ClassRunner, and it provides the bootstrapping support needed to start/deploy/stop services. Adding @RunWith and a configuration is whats required. There are also other ways to instantiate , discover and inject services that are required for testing, in such a way that you dont need external services. I think getting something useable for River here is really important for developers. I was hoping that maybe the committers that have worked with the test framework could provide some guidance here. > > 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. Yep. Something like mvn river:start-lookup If river had some standard scripts for starting services this would be an easier task. > > 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. It would be easier for me to see a project, any chance you can zip me something up and send it to me off-list? Thanks Dennis
