ctubbsii edited a comment on issue #1673: URL: https://github.com/apache/accumulo/issues/1673#issuecomment-674145929
My comment was copied to https://github.com/apache/accumulo/issues/1685#issuecomment-674185319 <details> <summary>Expand to view old comment:</summary> > [INFO] com.beust:jcommander .................................... 1.48 -> 1.78 There's breaking changes in newer jcommander, and is not safe to update in 1.x I think. > [INFO] com.google.auto.service:auto-service .............. 1.0-rc3 -> 1.0-rc7 > [INFO] com.google.code.gson:gson ............................... 2.7 -> 2.8.6 > [INFO] commons-cli:commons-cli ................................... 1.2 -> 1.4 > [INFO] commons-codec:commons-codec .............................. 1.4 -> 1.14 These should be fine, in general, but we should be careful about the `commons-*` ones. Some are riskier than others, and some we expect to be provided by, or matching, whatever Hadoop has. This is still an issue for Hadoop 2.x, and less so in Hadoop 3.x, where they have shaded much of their deps. In any case, 1.10 is supposed to be a stabilizing release, not one that could introduce weird dependency-related bugs. > [INFO] commons-collections:commons-collections ............ 3.2.2 -> 20040616 This is clearly not a newer version. :smiley_cat: > [INFO] commons-configuration:commons-configuration .............. 1.6 -> 1.10 I believe commons-configuration 1.10 ships some breaking changes. We've already updated in the main branch. I'd punt this one. > [INFO] commons-io:commons-io ..................................... 2.4 -> 2.7 > [INFO] commons-lang:commons-lang ................................. 2.4 -> 2.6 > [INFO] commons-logging:commons-logging ......................... 1.1.1 -> 1.2 Same comment above regarding being careful about `commons-*`. > [INFO] jline:jline ......................................... 2.11 -> 3.0.0.M1 This one is likely going to break the shell. > [INFO] junit:junit ............................................. 4.12 -> 4.13 This one will introduce a bunch of warnings, that have already been triaged in the main branch and updated there. It's a test dependency and not important to update here. > [INFO] org.apache.commons:commons-jci-core ....................... 1.0 -> 1.1 > [INFO] org.apache.commons:commons-jci-fam ........................ 1.0 -> 1.1 > [INFO] org.apache.commons:commons-lang3 ......................... 3.1 -> 3.11 > [INFO] org.apache.commons:commons-vfs2 ......................... 2.3 -> 2.6.0 More commons dependencies to be careful about. > [INFO] org.bouncycastle:bcpkix-jdk15on ......................... 1.62 -> 1.66 > [INFO] org.bouncycastle:bcprov-jdk15on ......................... 1.62 -> 1.66 Bouncycastle should be updated whenever we can, but I'm not even sure we still need it in newer JDKs. In any case, I believe this is a test dep, so it's probably fine. > [INFO] org.easymock:easymock ................................... 4.0.2 -> 4.2 Yes, if it doesn't break anything or introduce a bunch of warnings. I believe we've already updated the main branch. > [INFO] org.eclipse.jetty:jetty-http ........ 9.2.26.v20180806 -> 11.0.0.beta1 > [INFO] org.eclipse.jetty:jetty-io .......... 9.2.26.v20180806 -> 11.0.0.beta1 > [INFO] org.eclipse.jetty:jetty-security .... 9.2.26.v20180806 -> 11.0.0.beta1 > [INFO] org.eclipse.jetty:jetty-server ...... 9.2.26.v20180806 -> 11.0.0.beta1 > [INFO] org.eclipse.jetty:jetty-servlet ..... 9.2.26.v20180806 -> 11.0.0.beta1 > [INFO] org.eclipse.jetty:jetty-util ........ 9.2.26.v20180806 -> 11.0.0.beta1 I believe this is the last jetty that still supported Java 7. Since we now use Java 8 for the 1.10 branch, we can update, but not to a beta, and it won't be easy. All jetty updates seem to have breaking changes. I would pass on these. > [INFO] org.gaul:modernizer-maven-annotations ................. 1.8.0 -> 2.1.0 We can update any test/build tooling without much risk, so this one is fine to update, as is anything found by `mvn versions:display-plugin-updates`. However, there's diminishing returns on the effort, since we've already gone through a lot of this in the main branch already, and I'm not sure how much benefit there is to updating 1.10 when we're trying to stabilize it. > [INFO] org.powermock:powermock-api-easymock .................. 2.0.2 -> 2.0.7 > [INFO] org.powermock:powermock-core .......................... 2.0.2 -> 2.0.7 > [INFO] org.powermock:powermock-module-junit4 ................. 2.0.2 -> 2.0.7 > [INFO] org.powermock:powermock-reflect ....................... 2.0.2 -> 2.0.7 Test deps are fair game, but might require code changes. ---- In general, I'm in favor of updating plugin versions whenever we can, and test dependencies, too. Other deps need to be considered carefully, especially in maintenance branches where the risk of destabilizing things is greater. Also, should this have been a separate issue? :smiley_cat: </details> ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
