Modularisation of the directory structure and build of river is a large task, which might be used to replicate the current release artifacts, with the following exceptions:
Due to the dependency nature and structure of a modular build (see Dennis Reedy's attached river-modularisation-overview), certain classes provided by primary modules are excluded from dependent modules, contrary to the existing build, where all dependent classes other than platform api classes are included.
It is also worth noting modular dependency's and build structures are very relevant to Service API, to the implementation of services and proxy's and simplified development, which is possibly the main attraction of modular development frameworks.
With existing Jini and River releases, each client can potentially have a different plethora of classes loaded by it's application class loader, preferred class loading has been provided to deal with this, which brings another set of issues, documented by Mike Warres.
Sometimes change is an opportunity to consider other changes, such as the namespace change from com.sun.jini to org.apache.river, this is currently in the experimental stages and we're not certain if this should be done at the same time, but I'd like to keep the option open for now.
Client developers have been made aware of a policy that com.sun.jini are implementation classes only and not to be used, however a number of useful utility classes are included in com.sun.jini and will likely cause some client breakage (not proxys which have preferred class loading), when they're moved.
Making the build modular also makes our service implementations (that client developers are also free to implement) depend on parts of the build that are implementation only.
Considering that the only thing guaranteed to be installed at all clients is the platform jar, it is typical for service proxy's to have all needed classes available to them via download, utilising preferred class loading to ensure these classes are loaded, and not substituted by classes already loaded in the application class loader. So even with a modular build, there is still a need to maintain a level of compatibility with existing installations. In reality we will need to provide a jar file containing all the classes needed by proxy's downloaded to legacy clients.
In an ideal world, the application class loader would only contain classes and interfaces that are used by proxy's, client's and services to communicate with each other, child class loaders representing private namespaces would contain all implementation classes. In this world, preferred class loading would not be required and annotation loss would not occur. If the application classloader only contained service api and the jini platform, then a number of existing issues would disappear.
So the question remains: Why was the current platform jar structured how it is now?
What are the reasons and logic behind it's current design?
I think these are questions we need to ask as we explore the possibilities of a modular build structure.