Sent from my iPhone
> On Feb 11, 2014, at 8:22 PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > > Those recommendations are more applicable to application services than those > in the core River distribution. I disagree. River core services exhibit the same exact structure as application services, the only difference being that River services are produced by the River project. The referenced conventions mention Maven, but are applicable for other project/build tools, including Gradle. IMO, the most straight forward thing to do is to create a multi-module build that creates jars equivalent to the classdepandjar created jars. Regards Dennis > 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 >
