Bad luck for us then. Using SNAPSHOTs is not a solution we can accept, because builds relying on snapshots are impossible to reproduce.
OK, we'll find a way to do some monkey patching while waiting for 2.3.0. Then we will switch to it once it is released. Thank you again, Jean-Noel Le mer. 3 juin 2020 à 16:12, Andrew Gaul <g...@apache.org> a écrit : > I estimate 3-6 months since we just released jclouds 2.2.1. My goals > for 2.3.0 are fixing some of the dependency incompatibilities we have > accumulated over the last few years (see future of jclouds post). I > encourage you to use 2.3.0-SNAPSHOT for now. > > On Wed, Jun 03, 2020 at 10:08:37AM +0200, Jean-Noël Rouvignac (ForgeRock) > wrote: > > 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/ > > > > > -- > Andrew Gaul > http://gaul.org/ >
