Somehow I didn't get Greg's message earlier--just seeing the full text now.
I think the multiple modules resulting in multiple Eclipse projects (for instance) is a huge strength. Each artifact then has its own classpath and significantly reduces the possibility of compilation or runtime errors. Sure there's a little extra complexity in configuration, but that's to help ensure dependency resolution is correct. As devs we need to be responsible for the contents of our classpaths and Maven-repository-based tools are a huge help in that. Personally I far prefer Maven to Gradle. I do not see the ability to do custom scripting as an advantage and I find having an XSD schema to work from reduces errors. Scripting adds a lot of variables (no pun intended) and could lead to an increased support load. On the other hand, once we decide to use a dependency-based system over classdepandjar it shouldn't matter which flavor we use as long as it is compatible with Maven repository metadata. -j On Tue, Feb 11, 2014 at 5:22 PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > 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 > > > >
