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/

Reply via email to