Greg, Discussion ensues.
A little tangent here that might be of interest. I worked on modularizing Blitz with Dawid Loubser, if you're interested in seeing how that ended up (pretty much follows the conventions being discussed), check it out here https://github.com/DawidLoubser/blitz-javaspaces-modularised Regards Dennis On Feb 12, 2014, at 516PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > Hi Dennis: > > Some discussion inline… > > Greg Trasuk > > On Feb 12, 2014, at 4:16 PM, Dennis Reedy <dennis.re...@gmail.com> wrote: > >> Greg, >> >> I think how the River project is structured, built and tested becomes a >> recipe for how developers that use River can begin to create their own >> projects. So IMO its something to care about. As you point out, the current >> approach is based on decisions made over a decade ago and there are reasons >> to change (as have been pointed out). > > Is the Tomcat source code a recipe for how to structure web applications? Right, but Tomcat is not a web application. > All I’m saying is that the purpose of River’s build system is to build River, > and nothing more. So let’s think clearly about what we gain by restructuring > it. I agree on this generally but only for river-core components. When it comes to River services, we should set guidance by showing how the project builds it's services. IMO this is a plain and simple win for developers curious on they should build and test their services. > The biggest advantage I see is making it easier to maintain and update the > pieces separately (e.g. update Outrigger to use an open-source data store > instead of SnapLogStore, or create a clustered JavaSpace). Eventually I > think that leads to multiple deliverables with different release cadences, > but we certainly don’t need to start out that way. > > In any case, I think the recipe for how to develop applications has to be > shown with good examples, Sure, good examples are always important. > not River’s build system. For application developers, the mechanism to build > the artifacts that go into Central isn’t important. Building River services and deploying to central have nothing to do with each other. > As they say, “People who like laws and sausages probably shouldn’t watch > either one being made”. > >> >> If we choose to adopt conventions that produce a single jar per module, > > Apart from my griping about having a lot of IDE projects, I think a single > jar per module is the way to go. That will be much more clear about why the > modules exist, and we’ll avoid any possibility of having the same class in > different jar files (which we currently do have). > >> and that each module represent a basic architectural element of a >> distributed service, then we can begin to break out and organize the >> project. What I had started to do was to break out River as follows: >> >> apache-river/ >> river-core/ >> jsk-dl/ >> jsk-lib/ >> jsk-platform/ >> jsk-resources/ >> serviceui/ >> > > Don’t forget jsk-policy.jar Right, oversight on my part and hand typing this in I knew I was bound to miss something :/ > > Also, does anyone remember the rationale as to what goes into jsk-lib as > opposed to jsk-patform? Right now there’s some overlap between them. Whats the overlap? > I thought the idea was to just have jsk-platform.jar. > >> river-services/ [1] >> reggie/ >> reggie-proxy/ >> reggie-impl/ >> outrigger/ >> outrigger-proxy/ >> outrigger-impl/ >> outrigger-snaplogstore/ >> mahalo/ >> mahalo-proxy/ >> mahalo-impl/ >> mercury/ >> mercury-proxy/ >> mercury-impl/ >> > > Minor thing - could we keep it as “reggie-dl”, etc, rather than > “reggie-proxy”? To me, *-dl expresses the intention a little better, since > it’s all the classes that might need to be downloaded to the client, which > might include other support in addition to the proxy. Either naming will > work, but it would be good to be consistent. The proxy module calls out quite clearly what the module contains, and that one should never include a proxy module in one's classpath. However, if a service has an api module, that would become a classpath dependency for using a service, and have that service's proxy loaded dynamically (downloaded or loaded from the file system). To me I originally found the -dl.jar naming confusing. To the un-initiated, it is not obvious. Unless I know that dl means download, I have no idea what the dl is, encompasses or means. Using proxy seems quite clear. > In building modules for a container, it’s kind of nice to be able to pickup > on the name of the jar to indicate if it needs to go in the codebase > annotation. And proxy fits the bill quite nicely IMO. My service's annotation is the proxy, and clients use the api as a classpath dependency. > >> >> river-start/ >> >> river-tools/ >> browser/ >> classserver/ >> > > I’d almost put class server into the starter framework. I don’t think it’s > useful outside the service-starter. Meh. I use ServiceStarter, but not classerver. I use Rio's Webster. Some use Tomcat, some use Jetty. I wouldn't couple classerver with starter. > > The browser is actually (in the current structure anyway) in the ‘examples’ > directory. If you’re interested, I’ve already isolated it in the container > build. See > https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser;h=cdb48103dced2273fc62ab3857676afec3861ef2;hb=HEAD > and > https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=tree;f=browser-module;h=1a5897a11e1419055eefdfe6d439bd2d2f4d1cb0;hb=HEAD. Most have co-opted the browser, isolating it should not be an issue. > >> river-integration-tests >> > > I agree that the integration tests should probably stay as a separate module. > As time goes on it would be good to have unit tests in the other modules, > too. You want to ideally have unit tests coupled with each module. > >> Under each module (example reggie-proxy), we would have: >> >> src/ >> main/ >> java/ >> groovy/ >> (other languages...) >> resources/ >> test/ >> java/ >> groovy/ >> (other languages...) >> resources/ >> >> I think the most difficult and time consuming effort would be to try and >> merge in the current unit tests into each module. AFAIK, mots of the tests >> are integration tests, so putting them in their own module makes sense. >> >> We still have one deliverable, all we need to do is "assemble" the project >> into a distribution. This is a fairly simple thing to do with Maven (I'm >> sure it's not that difficult to do with Gradle either). >> >> Regards >> >> Dennis >> >> 1. In most cases an api module is not required for River core services since >> the API is defined is jsk-dl >> > > That’s probably open to argument. For example, is JavaSpace a “core” API? > It always seemed to me like it landed inside Jini because it needed a home (I > recall that at one time it was a separate project), but it seems more like an > application API. I’m not saying it _should_ or _shouldn’t_ be split out, but > it’s something to think about. Things like Registrar, however, seem to be > pretty “core”. Well, it is net.jini.space.JavaSpace, are you advocating to move it out of the net.jini namespace? Or, do you think that we should move all of the River service api's out of jsk-lib and put them specifically into an api module for each respective service? However, Outrigger is a contributed implementation of JavaSpace(05), so it does not make sense to put it into the outrigger module? Perhaps create a separate river-api module that includes all of net.jini service apis (Registrar, JavaSpace(05), TransactionManager,...). That might be a good idea. > > Overall, a good start on the modules. We’ll need to settle on a tool (maven, > Gradle, Ant, etc). I’m kind of with Simon on this - Maven is pretty > standard, and I’d probably vote for it in the absence of strong arguments for > a different build tool. Although I did notice as I was doing the container > work that it sometimes does impose limits on the actual application (for > example, I couldn’t for the life of me figure a clean way to get it to > generate a module with a “.ssar” extension without writing a plugin, which I > wasn’t at the time aware how to do, so I changed the deployment module to > “.jar”). For me, Maven would be the quickest. > > I’m assuming we’d wait to modularize until Peter declares ‘qa_refactor’ done, > and merges it back into the trunk? Sure, or do the work in qa_refactor (up to Peter). I'd also recommend that as part of this we change the com.sun.jini namespace to org.apache.river, and make sure that for each module, we follow consistent package naming conventions: org.apache.river.<module-name>.api org.apache.river.<module-name>.proxy api: org.apache.river.<module-name>.impl Lastly, I'd alter my original work to change river-core to: river-core/ river-dl/ river-lib/ river-platform/ river-resources/ river-policy river-serviceui/
