OK, here's the latest: The good news: I just managed to run "mvn clean compile package" and see (almost) everything run through successfully. I say almost because I commented out the groovy-config module, and all references to the gmaven plugin for now. This is because the Groovy and gmaven-plugin dependencies were pretty out of date when I looked earlier (but to be fair, that's when I was still using the wrong branch). Anyway, I didn't feel like trying to figure that part out.
The bad news: Aside from the aforementioned lack of success with the Groovy stuff, the bad news is as follows: I had to do ugly... brutally, hideously, grotesquely ugly things to make this work. The circular dependency thing proved to be a nightmare. As far as I can tell, the fundamental issue is that there is a fairly high innate level of coupling among a lot of the code that was spread across several modules. To the point that I don't see any easy way to keep that module structure and *not* have circular dependencies. And Maven can't build with circular dependencies, because it can't figure out what order to build things in when that happens. In the end, to work around this, I had to merge the code from several modules into one big honking module. Specifically, I combined all of river-lib, river-platform, river-discovery-providers, river-start, river-jeri, and part of river-dl. I put all that code into river-lib for now. Now, somebody who knows this codebase a lot better than me could probably see more easily how to cut the Gordian knot and do whatever refactoring would be needed to neaten this up. But for me, having worked *with* River just a little bit, but never having worked *on* River until now, it's all a bit opaque. Anyway, maybe somebody has even done that work and they're just sitting on their local changes for now. That would be the ideal case. Other things that fall into the "bad news" category, but are probably less important: 1. Since there were a few places the physical package structure didn't match the code, in each case I changed the code to match the actual file layout. This of course had follow-on effects, as I had to change imports to match, and I had to make a lot of classes, interfaces, and fields "public" that were package private before, in order to get it all to compile. 2. I didn't bother fixing up any of the OSGI stuff to account for (1) above. I just wanted to see it compile successfully. Anyway, I can create a patch and attach it to the Jira ticket if anybody thinks it would be useful. I don't think my heavy-handed brute-force approach left this in a state that even approach what is probably desired going forward, but maybe somebody else can use some bits and piece of this work to help get there. Oh, and last thing I was going to add... why does this matter, vis-a-vis the Gradle build? Not sure, but I *think* Gradle would have the same issue with circular dependencies among modules, and for the same reason. So whoever creates the Gradle build will have to deal with the same issues, I think. Phil
