Re: [DISCUSS] Move or remove org.apache.geode.admin
The way I interpret https://semver.org/, deprecated functionality should be removed in a major release. Users should be able to update to a new minor release without having to worry that any of their code will break. It's certainly more convenient for us to mark as deprecated and then remove whenever after the next major. It's unrealistic though that users will have kept track of what was deprecated before the previous major release came around and take that into account every time they upgrade a minor. In essence we'd expect the user to keep a list of what previously deprecated functionality they are still using and treat every minor upgrade like a major until that list is empty. That would be the only way for them to avoid these potential, very negative surprises. That said in this case it sounds like we already have broken large parts of this API. Regardless of how we chose to interpret semver we should be able to at least remove the parts of the API that's already broken. On Tue, Apr 2, 2019 at 6:55 PM Jinmei Liao wrote: > +1 since it's been deprecated pre geode 1.0, and I have no idea what its > purpose. > > On Tue, Apr 2, 2019 at 5:20 PM Jacob Barrett wrote: > > > > > > > > On Apr 2, 2019, at 5:04 PM, Dan Smith wrote: > > > > > > 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)? > > > > I think a deprecated API is no longer API after a major version > increment. > > The deprecated symbols can be removed anytime after the major release > with > > merely a notice in the release notes. I think its unrealistic to expect > all > > deprecated symbols be removed for the x.0 release. > > > > > 2) How about in this case, when this feature has been deprecated for so > > > long, and may or may not work? > > > > Given that this API was effectively deprecated in version 0 of Geode and > > was never part of the release API in 1 it is fair game now. Time should > not > > be a factor, just major version number. > > > > -Jake > > > > > > -- > Cheers > > Jinmei >
Re: Need edit access to cwiki
Using a different browser fixed the problem for me. On Tue, Apr 2, 2019 at 5:53 PM Jinmei Liao wrote: > I believe I used the Apache LDAP account, it's the same username anyway. I > still keep getting this error: > [image: Screen Shot 2019-04-02 at 5.52.14 PM.png] > > On Tue, Apr 2, 2019 at 3:12 PM Mark Bretl wrote: > >> Hi Jinmei, >> >> I have viewed your permissions and they look correct. When I click on edit >> page, it was successful in loading the editor. >> >> Did you login with your Apache LDAP account? It looks like INFRA has >> updated that fairly recently. >> >> --Mark >> >> On Tue, Apr 2, 2019 at 2:58 PM Jinmei Liao wrote: >> >> > Username is jinmeiliao. I used to have edit access, but now Confluence >> > throws "The editor didn't load this time" error when trying to edit a >> page >> > >> > -- >> > Cheers >> > >> > Jinmei >> > >> > > > -- > Cheers > > Jinmei > -- Cheers Jinmei
Re: [DISCUSS] Move or remove org.apache.geode.admin
> But this "hidden" feature, what is that? Is this something that we would > like to support or is this something that would be replaced with our > existing efforts in the ConfigurationService and Metrics area. > The old JMX agent [1] was superseded by the newer JMX manager [2] sometime before geode 1.0 was ever shipped. The agent script mentioned in the javadocs for the old jmx agent was never shipped with geode as far as I can tell, but you can launch an agent programmatically. Also the link to the descriptions of the mbeans is broken, but you can get an idea of what mbeans it had by looking the mbeans-descriptors.xml file in the source. [1] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/jmx/Agent.html [2] https://geode.apache.org/docs/guide/17/managing/management/list_of_mbeans.html
[Geode Build] Are the idea and eclipse plugins being used by anyone?
I'm eyeballing the ide.gradle file we have and am wondering if it is cruft from many iterations of both Gradle and IntelliJ/Eclipse ago. In my own IntelliJ workflow, I have always just asked IntelliJ to open the gradle project via the build.gradle itself, and it's easy to import other modules into my workspace via Import Module from Existing Sources... I've never had to deal with running ./gradlew idea to configure a project IML which I needed to merge against another project file. Is this the workflow others are using? Or is the idea plugin here a hanger-on that should be removed as no longer necessary? Also, as an IntelliJ user, I have zero experience on how the workflow for Eclipse is similar or different. The closures in our ide.gradle appear to be similar, but I don't have the Eclipse-side context to confirm or deny that. Thanks in advance for any additional insight. Imagination is Change. ~Patrick
Re: [Geode Build] Are the idea and eclipse plugins being used by anyone?
I tend to import into Intellij the way you have described. I've never used ./gradlew idea to configure. -michael On Wed, Apr 3, 2019 at 2:24 PM Patrick Rhomberg wrote: > I'm eyeballing the ide.gradle file we have and am wondering if it is cruft > from many iterations of both Gradle and IntelliJ/Eclipse ago. > > In my own IntelliJ workflow, I have always just asked IntelliJ to open the > gradle project via the build.gradle itself, and it's easy to import other > modules into my workspace via Import Module from Existing Sources... I've > never had to deal with running ./gradlew idea to configure a project IML > which I needed to merge against another project file. > > Is this the workflow others are using? Or is the idea plugin here a > hanger-on that should be removed as no longer necessary? > > Also, as an IntelliJ user, I have zero experience on how the workflow for > Eclipse is similar or different. The closures in our ide.gradle appear to > be similar, but I don't have the Eclipse-side context to confirm or deny > that. > > Thanks in advance for any additional insight. > > Imagination is Change. > ~Patrick >
Re: [Geode Build] Are the idea and eclipse plugins being used by anyone?
I was under the impression that intellij's import actually used some of the
information in the idea{} blocks in the build. See
https://docs.gradle.org/current/userguide/idea_plugin.html.
But if the import works well without that extra configuration, I think we
should get rid of it.
-Dan
On Wed, Apr 3, 2019 at 2:32 PM Michael Oleske wrote:
> I tend to import into Intellij the way you have described. I've never
> used ./gradlew
> idea to configure.
>
> -michael
>
> On Wed, Apr 3, 2019 at 2:24 PM Patrick Rhomberg
> wrote:
>
> > I'm eyeballing the ide.gradle file we have and am wondering if it is
> cruft
> > from many iterations of both Gradle and IntelliJ/Eclipse ago.
> >
> > In my own IntelliJ workflow, I have always just asked IntelliJ to open
> the
> > gradle project via the build.gradle itself, and it's easy to import other
> > modules into my workspace via Import Module from Existing Sources...
> I've
> > never had to deal with running ./gradlew idea to configure a project IML
> > which I needed to merge against another project file.
> >
> > Is this the workflow others are using? Or is the idea plugin here a
> > hanger-on that should be removed as no longer necessary?
> >
> > Also, as an IntelliJ user, I have zero experience on how the workflow for
> > Eclipse is similar or different. The closures in our ide.gradle appear
> to
> > be similar, but I don't have the Eclipse-side context to confirm or deny
> > that.
> >
> > Thanks in advance for any additional insight.
> >
> > Imagination is Change.
> > ~Patrick
> >
>
Re: [DISCUSS] Move or remove org.apache.geode.admin
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 be. 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] > > https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/package-summary.html > [2] Draft PR for moving the org.apache.geode.admin to a separate module - > https://github.com/apache/geode/pull/3392 >
Re: [DISCUSS] Move or remove org.apache.geode.admin
Would we announce that we aren't following semver anymore because bumping the major version is somehow too expensive? On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund wrote: > 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 > be. > > 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] > > > > > https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/package-summary.html > > [2] Draft PR for moving the org.apache.geode.admin to a separate module - > > https://github.com/apache/geode/pull/3392 > > >
Re: [DISCUSS] Move or remove org.apache.geode.admin
That’s your interpretation of semver. I interpret The API not to be broken within a major as those that are still valid when the major is released despite the availability of deprecated symbols from previous major. Just because I can access symbols does not make it API. API is the combination of documentation, annotation and availability of the symbols. If the symbols are available but marked deprecated and not documented anymore then it is. It API. Yes under your interpretation it would require that availability be removed at the major release too so that a consumer that ignore deprecation warnings when compiling with the new version got a compilation or runtime error later up updating a minor. I think that error is well deserved. We do a disservice to our customers by allowing them to continue to limp along on deprecated, unmaintained and untested APIs because we missed an arbitrary window to remove the symbols. If however the community agrees with you interpretation then we must make sure a ticket is created for the next major with a list of deprecated items and updated when new items are deprecated so that the task is performed at the major release. A chore needs to be undertaken to remove all deprecated APIs at the start of each major development cycle. The short of it is we can’t miss this arbitrarily limiting window. -Jake > On Apr 3, 2019, at 3:58 PM, Alexander Murmann wrote: > > Would we announce that we aren't following semver anymore because bumping > the major version is somehow too expensive? > >> On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund wrote: >> >> 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 >> be. >> >> 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] >>> >>> >> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/admin/package-summary.html >>> [2] Draft PR for moving the org.apache.geode.admin to a separate module - >>> https://github.com/apache/geode/pull/3392 >>> >>
