Hi Phil,
I've solved this circular dependency problem once before with JGDMS,
there were also circular package dependencies I wanted to avoid for OSGi
users, so it will be a good opportunity to take another look at this
problem, so we've got the best possible solution.
I'm familiar with the code, but I prefer to work with more than one set
of eyes. ;)
Note that packages in org.apache.river are implementation classes, which
can break backward compatibility if necessary, apart from
org.apache.river.api and net.jini which are the public api and need to
remain backward compatible.
River 3.0 broke backwards compatibility with the the com.sun.jini
package namespace by renaming it to org.apache.river. I've created a
compatibility layer module to provide a migration path for client code
still using River 2.x, I've used Rio as my guideline for what
com.sun.jini.* packages client code depended on, others can be added as
required. Using a compatibility layer module for breaking changes
appears to be a good approach.
Cheers,
Peter.
On 7/6/2020 4:41 AM, Phillip Rhodes wrote:
On Sun, Jul 5, 2020 at 8:07 AM Peter Firmstone
<peter.firmst...@zeus.net.au> wrote:
Hi Phil,
I've been going through your patch, you've got a lot of work done in a
short time. :)
I've just committed your changes.
I'll have a look at the circular dependencies and see what I can do in
the coming week.
Sounds good. I may also be able to free up some time to work on that
some more. I thought I'd try slowly moving classes back to their
original locations, from where I moved them to river-lib, and try to
isolate the absolute smallest number of classes that are circularly
dependent.
Although it may turn out that you, or somebody else who knows this
code better, may be able to just jump in and quickly work it all out.
Hopefully that will be the case, and will moot the need for the
exercise described above. :-)
In any case, all of this is good for me as far as getting familiar
with the River code in general.
Phil
