geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <>
Subject Re: [DISCUSS] Move or remove org.apache.geode.admin
Date Wed, 03 Apr 2019 22:29:26 GMT
1) +1 YES. If we continue to *not* have at least one major release per
year, then I 100% support the removal of deprecated APIs and features in a
minor release such as 1.10. If we decide to have at least one major release
per year, then I'd be willing to revisit this and consider not allowing
removal in a minor release. I do *not* support perpetually deferring major
releases to avoid facing the removal of deprecated APIs -- that's just
ridiculous as it keeps our maintenance costs much higher than they need to

2) +1 to remove anything in 1.10, or any other minor release, that was
already deprecated in Geode 1.0

On Tue, Apr 2, 2019 at 5:05 PM Dan Smith <> wrote:

> Hi devs,
> The org.apache.geode.admin package has been deprecated for about 7 years
> [1].
> I'd like to remove it, or at least move it to a separate module. I actually
> started some work to move it to a separate module [2]. However in the
> course of this process, I've found that this module has extremely little
> test coverage, so I'm not confident in the move. For example, it has a
> whole JMX manager feature (different than our current JMX manager) which
> does not appear to have any tests. This JMX manager feature won't work as
> shipped unless you find and add some mx4j jars to your classpath.
> I think the best course of action is probably to remove it entirely.
> However, this does bring up a couple of questions:
> 1) Is it ok in general to remove deprecated API in a non X.0 release (eg
> geode 1.10 instead of geode 2.0)?
> 2) How about in this case, when this feature has been deprecated for so
> long, and may or may not work?
> -Dan
> [1]
> [2] Draft PR for moving the org.apache.geode.admin to a separate module -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message