Hi Phil,
Wow, you're really getting into the code, thank you.
It's late here, I'll post again in the morning, just some quick
clarifications, the discovery providers depend on the platform, but the
platform shouldn't depend on the discovery providers, try removing that
dependency from the platform pom.
There will be some classes that need untangling.
The modular build is based on a fork of River that uses Maven called
JGDMS, all of the code in the fork is available to the project, however
the intent is to do the modular build without that code if possible, the
reasons for this are historical as changes in the fork are intended to
be brought it gradually and it's possible not all changes will be
accepted by the community. The River modular build doesn't need to
replicate the fork, but please feel free to use it for guidance.
The classes you've found with incorrect package declarations have been
moved from their original package, however the code itself has not been
updated to reflect the change. Also moving these classes hasn't been
reviewed or accepted by the River community at this stage.
The fork is available here:
https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS
Cheers,
Peter.
On 7/4/2020 3:53 PM, Phillip Rhodes wrote:
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
