BTW I was confused by seeing both these repositories in github: 1. https://github.com/jclouds/jclouds 2. https://github.com/apache/jclouds
I originally stumbled upon jclouds/jclouds via a google search, but it is not the correct one. The correct one is apache/jclouds. I was wondering if you had any control over the jclouds/jcloudsrepo, and whether you could delete it altogether? Thanks, Jean-Noel Le mer. 3 juin 2020 à 10:08, Jean-Noël Rouvignac (ForgeRock) < jean-noel.rouvig...@forgerock.com> a écrit : > Thank you very much! > We have very recently switched to Guava 29.0, prior to that we've been on > 26.0 a year or more ago. > > Now we have a new release coming up very soon, I was wondering if there > was a minor release planned for Apache JClouds very soon? (in the coming > month) > Otherwise we will have to resort to some sort of monkey patching, > substituting Apache JClouds' DnsNameValidator class with a patched one. > > Thanks again! > > > Le mer. 3 juin 2020 à 02:18, Andrew Gaul <g...@apache.org> a écrit : > >> This is merged now; thank you for your contribution. Does our CI run >> against Guava 26? It might be interesting to create a Modernizer custom >> violations file with all the removed methods in newer Guava versions: >> >> https://github.com/gaul/modernizer-maven-plugin >> >> On Thu, May 28, 2020 at 07:08:15PM +0200, Jean-Noël Rouvignac (ForgeRock) >> wrote: >> > Great, thank you for your quick feedback. >> > >> > We are testing the fix right now, so I will open a PR once we prove to >> > ourselves that it works. Of course there is a boolean bug :) >> > I will favour the code change that relies on the Java API rather than >> > bumping the guava version: it is more sustainable. >> > >> > >> > >> > Le jeu. 28 mai 2020 à 16:08, Andrew Gaul <g...@apache.org> a écrit : >> > >> > > This seems reasonable; please submit a pull request via GitHub. >> > > Alternatively we would accept a pull request which upgrades Guava to >> > > 19.0 although this might cause other version incompatibilities. >> > > >> > > On Thu, May 28, 2020 at 03:41:53PM +0200, Jean-Noël Rouvignac >> (ForgeRock) >> > > wrote: >> > > > Hello, >> > > > >> > > > I am looking at https://issues.apache.org/jira/browse/JCLOUDS-1491, >> and >> > > > specifically the use of deprecated (and now removed) guava APIs in >> code >> > > > used to support Azure cloud storage. >> > > > >> > > > If I understand correctly, updating the guava version is a >> challenge due >> > > to >> > > > dependencies on Apache Karaf. >> > > > >> > > > However, CharMatcher.JAVA_LETTER_OR_DIGIT has been removed in guava >> 26.0, >> > > > and CharMatcher.javaLetterOrDigit() should be used instead since >> guava >> > > > 19.0. Note that CharMatcher.javaLetterOrDigit() was immediately >> > > deprecated >> > > > in Guava 26.0, and java.lang.Character.isLetterOrDigit(int) should >> be >> > > used >> > > > instead. >> > > > >> > > > So it looks possible to get rid of the dependency on >> > > > CharMatcher.JAVA_LETTER_OR_DIGIT with the fix at the bottom of this >> email >> > > > (I think I may not need the check on the string emptiness, but I am >> not >> > > > 100% sure): >> > > > >> > > > What do you think? >> > > > >> > > > Thanks, >> > > > Jean-Noël >> > > > >> > > > >> > > > >> > > > $ git diff >> > > > diff --git >> > > > >> > > >> a/core/src/main/java/org/jclouds/predicates/validators/DnsNameValidator.java >> > > > >> > > >> b/core/src/main/java/org/jclouds/predicates/validators/DnsNameValidator.java >> > > > index 1102cb8435..fa14b1d510 100644 >> > > > --- >> > > > >> > > >> a/core/src/main/java/org/jclouds/predicates/validators/DnsNameValidator.java >> > > > +++ >> > > > >> > > >> b/core/src/main/java/org/jclouds/predicates/validators/DnsNameValidator.java >> > > > @@ -46,11 +46,10 @@ public class DnsNameValidator extends >> > > Validator<String> >> > > > { >> > > > } >> > > > >> > > > public void validate(String name) { >> > > > - >> > > > if (name == null || name.length() < min || name.length() > >> max) >> > > > throw exception(name, "Can't be null or empty. Length >> must be >> > > " + >> > > > min + " to " + max >> > > > + " symbols."); >> > > > - if (CharMatcher.JAVA_LETTER_OR_DIGIT.indexIn(name) != 0) >> > > > + if (!name.isEmpty() && >> Characters.isLetterOrDigit(name.charAt(0))) >> > > > throw exception(name, "Should start with letter/number"); >> > > > if (!name.toLowerCase().equals(name)) >> > > > throw exception(name, "Should be only lowercase"); >> > > > >> > > > >> > > > However, it looks like it is possible to get rid of the use of >> > > > CharMatcher.JAVA_LETTER_OR_DIGIT . >> > > > >> > > > >> > > >> https://bugster.forgerock.org/jira/browse/OPENDJ-7166?focusedCommentId=190259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-190259 >> > > >> > > -- >> > > Andrew Gaul >> > > http://gaul.org/ >> > > >> >> -- >> Andrew Gaul >> http://gaul.org/ >> >
