I've been working on creating a modular version of the project in the qa_refactor branch. The approach I've taken is to develop a Groovy script to load existing River jars, iterate through the contents of each jar, and copy sources to a multi-module project. The basic assumption with the multi-module project is that each module produces one jar.
If you checkout qa_refactor, go to the modularize directory and run ModularizeRiver.groovy (you'll need groovy in your path). This will populate the source tree into the multi-module project, reading each jar for it's contents, placing PREFERRED.LIST and any META-INF/service files into their correct location for inclusion into respective jars. I've also taken care to not duplicate classes across modules. I've taken the initial approach to use Maven, and once the multi-module project is populated with source (using ModularizeRiver.groovy), you can cd into it and run mvn install to produce a release that is in the apache-river/dist/target/apache-river-3.0-SNAPSHOT directory. A this point I'm soliciting opinions and thoughts. Note that using Gradle is certainly an option here, the breakout into multi-modules is not tied to Maven, it's based on accepted conventions. I chose Maven because it was the quickest (for me) to get going. I've included *most* of the River platform and services. I haven't gotten around to others based simply on time. This is an experiment, it's located in skunk/qa_refactor, and may help us think a little more about what River The multi-module project might look like. I do want to note, that this currently fixes absolutely nothing. There is nothing wrong with the current River build. This simply offers a different way of structuring River, using a multi-module project, where each module reflects the basic architectural element of a distributed system. Regards Dennis
