Those recommendations are more applicable to application services than those in the core River distribution. FWIW, however, the core services are already mostly structured this way - downloadable classes are all in *-dl.jar files (e.g. reggie-dl.jar, mahalo-dl.jar, etc). The only difference is that the core API classes like Registrar, JavaSpaces, etc, are in jsk-platform.jar.
Now, I think most of us would agree that the ‘classdepandjar’ mechanism is a little clunky, so restructuring the build may help with that. I have been using Maven to build applications (e.g. the samples at https://github.com/trasukg/river-container-examples). The only thing I find slightly irritating is that you end up with a proliferation of Maven modules, which equates to a proliferation of Netbeans or Eclipse projects. With Maven, that’s unavoidable, because Maven really really wants to have only one artifact produced per module. So ‘hello-api’ requires its own module, as does ‘hello-service’ (for the implementation code), and ‘hello-module’ (the packaging for the container). ‘hello-dl’ would be another, if there were a smart proxy. That’s also not specific to Jini projects; you get the same thing in JEE6 projects - separate projects for the JPA module, EJB module, EJB API, Web module, etc. Other build tools may be happier with multiple artifacts from one project. Ant certainly is, but of course you drift into the complexities of the current build with ‘classDepAndJar’. I think the first step might be to split out the infrastructure services like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the contents of jsk-platform in the core module. We’ll have to do some thinking about how to structure the integration testing for that. Cheers, Greg Trasuk On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <rafal.krupin...@sorcersoft.com> wrote: > Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze: >> On 11-02-14 11:35, Peter wrote: >> >>> We will need a new build system for java 8, this looks like a step in that >>> direction. In reality we need to adopt the build conventions used by Rio. >> >> What are these? Maven? > > Not necessarily Maven, although Dennis mentions it. > http://www.rio-project.org/conventions.html#Project_Modules > > It works very well for our River/Rio services. > > Regards > Rafał Krupiński >
