@Dan,
I will add my -1 to this.
I understand your argument of "let's solve the problem by removing the
offender".
But in reality who is the offender? Is it the one class that is using an
"internal" api OR is it the implementation itself that is to tightly
coupled that extending it is impossible?
STDG right now is trying to create a test, to test functionality that
requires it to inject/mock a Pool. The smallest piece of the code, not
the WHOLE PoolManager. But the system does not allow for the injection
of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
arguments). It casts every generic `Pool` to its implementation. This is
a very limiting factor.
I understand that delaying a release is not optimal, but how much effort
to we believe it to be to clean up the code that so tightly couples
implementations together.
I think we also must not forget that John, like many of us, is a
committer and PMC member on Geode. He also happens to be the main
committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
should not go out without fixing a limiting feature to the Geode
project, then he may do so.
I also feel that this is a limiting factor.
The only difference is that I am not the main committer on the Spring
data projects for Geode. John is merely trying to get the best outcome
for both projects.
--Udo
On 12/4/19 4:39 PM, Dan Smith wrote:
Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.
What bothers me here is not your suggestions in GEODE-1753, but the fact
that you are vetoing a Geode release because STDG is using an internal
Geode method and had a problem.
How hard is it to remove the use of PoolManagerImpl from STDG? If we can
fix the issue there, that seems better than putting bandaids into the
release branch so STDG can continue to use internal APIs.
-Dan
