From user-return-2933-archive-asf-public=cust-asf.ponee.io@jclouds.apache.org Thu Mar 18 08:17:18 2021 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org [95.216.194.37]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id E710C180686 for ; Thu, 18 Mar 2021 09:17:18 +0100 (CET) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-he-de.apache.org (ASF Mail Server at mxout1-he-de.apache.org) with SMTP id 916076449F for ; Thu, 18 Mar 2021 08:17:06 +0000 (UTC) Received: (qmail 23204 invoked by uid 500); 18 Mar 2021 08:17:05 -0000 Mailing-List: contact user-help@jclouds.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@jclouds.apache.org Delivered-To: mailing list user@jclouds.apache.org Received: (qmail 23194 invoked by uid 99); 18 Mar 2021 08:17:05 -0000 Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org) (116.203.196.100) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Mar 2021 08:17:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamproc1-he-de.apache.org (ASF Mail Server at spamproc1-he-de.apache.org) with ESMTP id EAB261FF3A8 for ; Thu, 18 Mar 2021 08:17:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamproc1-he-de.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mx1-ec2-va.apache.org ([116.203.227.195]) by localhost (spamproc1-he-de.apache.org [116.203.196.100]) (amavisd-new, port 10024) with ESMTP id FMtnSBa5qEoT for ; Thu, 18 Mar 2021 08:17:04 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.217.53; helo=mail-vs1-f53.google.com; envelope-from=jean-noel.rouvignac@forgerock.com; receiver= Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 055D3BD0E0 for ; Thu, 18 Mar 2021 08:17:03 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id l4so1073135vsc.7 for ; Thu, 18 Mar 2021 01:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7RW5vsDsd03S5k+isqFuJxrEdbLow/rNAg4tUArm2g4=; b=CSNvQ/taOlHGC5UOwxHZh0z9wDHtehwt5SOjK95V7Vt4NlqggIsU/4GCIMIW6TIRj+ xEfr/SXoXfN42r0AP1GEgClC/4syAok7n0aGZ6jAnM92SNMNtbMZMk6ElqEogvldjqTj VDHwj1TA0KnmcizwRsYVh/BzOQPZYkTjGUYsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7RW5vsDsd03S5k+isqFuJxrEdbLow/rNAg4tUArm2g4=; b=Sh5rdGHsUbFBkKZil8/oAGKgSsTHzJSEU7NUYdJQwS3LzqTT9MNZ/Xy3iL+m6//fL/ xzObjtz6B7zsScFCIWJOYNyznSrIuGBi+2f0Q3I8pEhz6OgqIrnqKrmYe+JrjHMujsk0 a84EHragS3Ry98WZMY6pbV0mIXOc4MCLfifO9pKgh5Goz3bIKl/fbWn/zHy+6vj3bSiE AMwTm/9hK6vjKwGtIuDNOLzIhGQZuZjWEffKCX/SOfFJQWoEN1EBZbcfuOo/YfZEe3p+ 7Um5ZrvVLztcb7IFfwCIuwffNUamYCBVQOzPIXdtydHUAyNgNCJz6LOaANA2wXzQ9rKo NuXQ== X-Gm-Message-State: AOAM533U2z+G/xHad6nXzdf0b52ChduyY7x4gFph2D3ailzUY747TUUA Y8pi82OMsmmz/1hlLjpdugQdYSkKGmpnSaUd+qnzz0D4vcdHbxOfP8oKmfMIFlmrz6Nsk99kLLa 6NGzKANojaN5PqPsZgf+XCyQqk6ukcdL6AQ== X-Google-Smtp-Source: ABdhPJwlEMCIQsIq14p7ZOqUPPP6uHeqSEgZepALkg3gIOlZNoDCHYuOQOU9BM20X7AYQ1n2k04YtiC/ZW+kja9OvBM= X-Received: by 2002:a67:77d3:: with SMTP id s202mr6024677vsc.5.1616055422374; Thu, 18 Mar 2021 01:17:02 -0700 (PDT) MIME-Version: 1.0 References: <25b0e301-af80-768f-0ac5-626a383533f7@fritz-elfert.de> <29c99736-bea6-3c96-5ef0-fce9978063eb@fritz-elfert.de> In-Reply-To: <29c99736-bea6-3c96-5ef0-fce9978063eb@fritz-elfert.de> From: =?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac_=28ForgeRock=29?= Date: Thu, 18 Mar 2021 09:16:51 +0100 Message-ID: Subject: Re: [ANNOUNCE] Apache jclouds 2.3.0 released To: user@jclouds.apache.org Content-Type: multipart/alternative; boundary="00000000000063699105bdcb39e5" --00000000000063699105bdcb39e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The experience with shading in my company is mixed at best. Yes you go past the classpath issue, but then it becomes a maintenance nightmare if any vulnerability is detected on the shaded version (true story). Another problem may be that vulnerability scanners may not detect shaded library and fail to report vulnerability issues. Then a dependent project has to open the jar at build time, rehade the vulnerable library and repackage the original jar into your own version. Nobody wants to do that. The real problem is that guava does not follow semantic versioning. And there's no cure for that. Despite all its goodness, guava is not a great dependency to have because of that. It works well for them because they are in a monrepo and have powerful refactoring tools to fix all their codebase in a single commit. Conclusion: there is no magic answer to solving this problem and I did not contribute much to helping you with it. Side note: I am interested in helping reduce the reliance on guava (as I did with xmlbuilder). I am not even contemplating getting rid of it given how deeply it is used. But we need to start somewhere. Less adherence =3D=3D potentially less brea= kage. Le jeu. 18 mars 2021 =C3=A0 08:57, Fritz Elfert a = =C3=A9crit : > On 18.03.21 01:21, Andrew Gaul wrote > [...]> Guava versioning is a perennial source of frustration to users and > > maintainers. Unfortunately jclouds (and specifically me) made poor > > choices by using Guava types in public interfaces. I created some > > tooling to address this but did not make much progress fixing jclouds > > itself: > > > > https://github.com/gaul/interface-maven-plugin > > > Thanks for the link. However, at a first glance, this looks more > like a tool for warning about undesired class usage. The jenkins > parent pom already uses the maven-enforcer-plugin which does something > similar (and more) but at pom level (e.g.: in jenkins it blocks > transitive dependency on newer guice/java for any plugin) > > > Would Guava/Guice vendoring work given the existing mess? Could you > > hack up a partial proof of concept to see if it would work? Vendoring > > has other caveats so let's what others say. > > > I am not familiar with the term vendoring. What is that? > > I only know shading using the maven-shade-plugin. E.g.: This > has been used in jclouds in the past (was removed though at a later point > in time): > > https://github.com/apache/jclouds/pull/35 > > Thanks > -Fritz > --=20 ForgeRock values your Privacy --00000000000063699105bdcb39e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The experience with shading in my company is mix= ed at best.
Yes you go past the classpath issue, but then it becom= es a maintenance nightmare if any vulnerability is detected on the shaded v= ersion (true story). Another problem may be that vulnerability scanners may= not detect shaded library and fail to report vulnerability issues.
Then a dependent project has to open the jar at build time, rehade t= he vulnerable library and repackage the original jar into your own version= . Nobody wants to do that.
The real problem is that guava doe= s not follow semantic versioning. And there's no cure for that. Despite= all its goodness, guava is not a great dependency to have because of that.= It works well for them because they are in a monrepo and have powerful ref= actoring tools to fix all their codebase in a single commit.

= Conclusion: there is no magic answer to solving this problem and I did not = contribute much to helping you with it.

Side note: I am = interested in helping reduce the reliance on guava (as I did with xmlbuilde= r).
I am not even contemplating getting rid of it given how d= eeply it is used.
But we need to start somewhere. Less adhere= nce =3D=3D potentially less breakage.


Le=C2=A0jeu. 18 mars 202= 1 =C3=A0=C2=A008:57, Fritz Elfert <fritz@fritz-elfert.de> a =C3=A9crit=C2=A0:
On 18.03.21 01:21, Andrew Gaul wrote<= br> [...]> Guava versioning is a perennial source of frustration to users an= d
> maintainers.=C2=A0 Unfortunately jclouds (and specifically me) made po= or
> choices by using Guava types in public interfaces.=C2=A0 I created som= e
> tooling to address this but did not make much progress fixing jclouds<= br> > itself:
>
> https://github.com/gaul/interface-maven-plugin
>
Thanks for the link. However, at a first glance, this looks more
like a tool for warning about undesired class usage. The jenkins
parent pom already uses the maven-enforcer-plugin which does something
similar (and more) but at pom level (e.g.: in jenkins it blocks
transitive dependency on newer guice/java for any plugin)

> Would Guava/Guice vendoring work given the existing mess?=C2=A0 Could = you
> hack up a partial proof of concept to see if it would work?=C2=A0 Vend= oring
> has other caveats so let's what others say.
>
I am not familiar with the term vendoring. What is that?

I only know shading using the maven-shade-plugin. E.g.: This
has been used in jclouds in the past (was removed though at a later point in time):

https://github.com/apache/jclouds/pull/35

Thanks
=C2=A0 -Fritz

ForgeRock values your Privacy --00000000000063699105bdcb39e5--