I agree with Dennis--modern dependency management is way more elegant and less error-prone than classdepandjar.
-j On Tue, Feb 11, 2014 at 6:35 PM, Dennis Reedy <dennis.re...@gmail.com>wrote: > > > 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 > > >
