OK, for the sake of my own edification if nothing else, I've been plowing ahead with making the various changes needed to get all of this stuff to compile. I'm pretty close (in relative terms anyway) to having everything compiling, but now I've hit something that I think I need to get everyone else's thoughts on.
In the module river-discovery-providers, we have at least one class (one example, X500Provider) which depends on two classes that are in module river-platform. import org.apache.river.discovery.DatagramBufferFactory; import org.apache.river.logging.Levels; The problem is, you can't declare a dependency on river-platform from river-discovery-providers, because there is apparently something(s) in river-platform that depends on river-discovery-providers. So if you try this, Maven errors out with a "circular dependency error". I think we're going to need to shuffle a class or two around to avoid this, but I don't know enough about the semantics and intent of any of this code to have a good feel for the best way to approach that. I mean, I could probably futz around with it and come up with something that will compile, but it probably wouldn't make sense. Any thoughts on how to deal with this? Phil On Fri, Jul 3, 2020 at 6:26 PM Phillip Rhodes <motley.crue....@gmail.com> wrote: > > OK, sounds good. > > Another question: it looks like some packing renaming / code > restructuring has gone on as part of this effort, unless I'm missing > something. I see things like class DestroySharedGroup having a package > statement at the top like > > package org.apache.river.start; > > but it's physical location is now org/apache/river/start/destroy, and > so the compiler complains that the declared and actual packages don't > match. > > There are quite a few examples of this. Is there any simple heuristic > to know which one is right? eg, a rule saying "the declared package in > the code is right" OR "the actual physical location is right and the > package declaration should change." > > Just for grins and giggles I stared down the path of doing the latter > to see if I could get things to compile, and I find that that also > causes issues due to things like package visibility. Some classes > depend on references to fields in other classes that are not visible > if you use the "altered" package declaration. For example, the > aforementioned DestroySharedGroup references fields on ServiceStarter > and ServiceDescriptor that were "package private". For example, the > ServiceStarter.logger field. > > Any advice on the best way to resolve these things? > > > Phil
