I reviewed the PR. Looks like it's headed in a good direction. I wouldn't bother creating a 1.10 branch. We can do that after we tag a release and do the normal branch cleanup.
On Mon, Dec 23, 2019 at 9:37 AM Mike Miller <mmil...@apache.org> wrote: > > I am working on a 1.10 branch which is the 1.9 branch + JDK8 + > updates/ignores to appease the modernizer. @Christopher > <ctubb...@gmail.com> I took your changes to PropertyType from your branch > and they look pretty good. I think we are able to update a lot in that > class since it is fairly self contained. A lot of the updates to > configuration classes though, I will just annotate with @SuppressModernizer > since we can't drop Mock in a 1.10 release. I just started the work but > was wondering how I should push the branch. Do you want to review it on a > PR against 1.9 that I can push in a 1.10 branch? Or want me to just create > a 1.10 branch in the main repo whenever its ready and send out a link for > folks to review? > > On Wed, Dec 11, 2019 at 1:34 PM Christopher <ctubb...@apache.org> wrote: > > > I think the main hold up is that I had committed to doing the JDK8 > > changes we discussed to get a 1.10, and I haven't had time to finish > > following through (too focused on 2.1 development and other tasks). I > > had thought there was interest in a 1.10, but for me, I'd be just as > > happy aborting that plan and sticking with maintaining the 1.9 line. > > Then, neither I nor anybody else has to bother doing any JDK8 changes > > or dealing with the modernizer plugin. I'm reluctant to simply ignore > > the plugin, since it does highlight quality issues that we don't want > > to become worsened over time if we simply ignore it. I'd much prefer > > to abort the 1.10 plan and stick to supporting 1.9 as the LTS release, > > and doing a 1.9.4. I don't want to do both because I don't want to > > support both. > > > > If we drop the 1.10 plans, I think we could do a 1.9.4 release pretty > > quickly (I could prepare a test release candidate pretty much right > > away to star the ball rolling, and an RC1 within a week). But, I don't > > want to go against what the community agreed to, by vote, without > > another vote (which I don't want to champion). > > > > On Wed, Dec 11, 2019 at 10:15 AM Adam Lerman <aler...@gmail.com> wrote: > > > > > > I agree with Mike that one or the other should happen. If the hold up is > > > the modernizer plugin, and we know those issues are addressed in 2.0+, > > > maybe we consider ignoring those issues in the 1.10 line. > > > > > > On Wed, Dec 11, 2019 at 9:57 AM Mike Miller <mmil...@apache.org> wrote: > > > > > > > If the demand is still there for a 1.10, I am willing to help out. > > But in > > > > the meantime, we could still release a 1.9.4, regardless of whether we > > have > > > > a 1.10 or not. The last bug fix for 1.9 was in April and there have > > been > > > > some fixes and improvements that users are waiting on. > > > > > > > > On Tue, Nov 12, 2019 at 8:24 PM Michael Wall <mjw...@gmail.com> wrote: > > > > > > > > > Thanks Christopher. > > > > > > > > > > On Tue, Nov 12, 2019 at 3:48 PM Christopher <ctubb...@apache.org> > > wrote: > > > > > > > > > > > It was pointed out to me that some of the problems I had using the > > > > > > modernizer-maven-plugin could be alleviated by adding granular > > > > > > exceptions in the modernizer config. I'll see if I can make that > > > > > > happen. > > > > > > > > > > > > On Fri, Nov 8, 2019 at 7:14 PM Christopher <ctubb...@apache.org> > > > > wrote: > > > > > > > > > > > > > > So, one of the problems I've run into migrating the 1.x code to > > JDK8 > > > > > > > is that we still have Mock in the API. That was removed in 2.x. > > > > > > > However, in 1.9, MockConfiguration extends a non-public API, > > > > > > > AccumuloConfiguration, which uses non-public Guava types for > > > > > > > Predicates. Code-modernization/quality checks performed by the > > > > > > > modernizer-maven-plugin catch the use of Guava's Predicate. I'm > > still > > > > > > > looking at this, to see if I can work around it without breaking > > > > > > > anything, but it's a bit frustrating, especially since the right > > fix > > > > > > > (removal of Mock) was already done in 2.x. > > > > > > > > > > > > > > I'll revisit next week after a long weekend. In the meantime, if > > > > > > > anybody is having second thoughts about a 1.10 release, or > > opinions > > > > > > > about what to do, feel free to express them here. One option is > > to > > > > > > > simply disable the modernizer-maven-plugin and ignore those > > checks... > > > > > > > but I don't really like the idea of disabling one of our tools > > that > > > > > > > does quality checks (even if these are very minor quality items). > > > > > > > > > > > > > > On Thu, Nov 7, 2019 at 4:20 PM Christopher <ctubb...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > > As agreed in the recent [VOTE] thread, we will be releasing a > > > > 1.10.0 > > > > > > > > that bumps the minimum runtime Java version to 8. > > > > > > > > > > > > > > > > I am beginning to work on getting the branch (currently still > > named > > > > > > > > 1.9) ready for release in accordance with this plan. As such, I > > > > will > > > > > > > > be preparing a pull request that bumps the Java version and > > > > resolves > > > > > > > > any errors generated by our plugins which do quality checks > > > > > > > > (specifically modernizer, but also some compiler warnings). > > > > > > > > > > > > > > > > However, there are still a few other outstanding issues that > > were > > > > > > > > previously labeled for 1.9, which have not yet been resolved. > > At > > > > > least > > > > > > > > one of these was labeled a "blocker". These are: > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/accumulo/issues?q=is%3Aopen+project%3Aapache%2Faccumulo%2F8 > > > > > > > > > > > > > > > > If anybody is able to work on these, it will be very helpful in > > > > > > > > getting the 1.10.0 ready for a release vote. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Christopher > > > > > > > > > > > > > > > > >
