On 18.03.21 15:38, Andrew Gaul wrote:
On Thu, Mar 18, 2021 at 02:21:57PM +0100, Fritz Elfert wrote:
On 18.03.21 12:14, Andrew Gaul wrote:
This is something we could experiment with although there are more
considerations for upgrading dependencies than simply getting the latest
version, as the
On Thu, Mar 18, 2021 at 11:38:02AM +0100, Fritz Elfert wrote:
> Jean-Noël mentioning security scanners in our recent discussion make me think:
>
> It would be nice to have depedabot enabled in the github repo settings
> (Security & analysis).
> If both alerts and security updates are enabled, it
> But in general you are right of course. For me in particular, the problem
is: I cannot shade transient dependencies, because all the imports in
jclouds have to be
changed accordingly. Therefore, doing the shading in jclouds ist the only
intermediate way to get the new jclouds into my jenkins
Jean-Noël mentioning security scanners in our recent discussion make me think:
It would be nice to have depedabot enabled in the github repo settings (Security
& analysis).
If both alerts and security updates are enabled, it automatically creates pull
requests for the relevant changes.
Cheers
On 18.03.21 09:16, Jean-Noël Rouvignac (ForgeRock) wrote:
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
I have started looking at ListenableFuture.
TBH I don't know where to start! A lot of things are public, so I don't
think I can change them straight from ListenableFuture to CompletableFuture?
They are also often used in conjunction with ListeningExecutorService which
makes the problem worse.
I
On Thu, Mar 18, 2021 at 09:38:19AM +0100, Jean-Noël Rouvignac (ForgeRock) wrote:
> Thanks for highlighting ListenableFuture for a start. Given the size of
> jclouds (about 400kLOC of production code with a stupid wc -l) and my
> inexperience of its codebase, I need help to know where to start. :)
Great!
Thanks for highlighting ListenableFuture for a start. Given the size of
jclouds (about 400kLOC of production code with a stupid wc -l) and my
inexperience of its codebase, I need help to know where to start. :)
I'll see what I can do about it. Do you want to create an issue that
describes
On Thu, Mar 18, 2021 at 09:16:51AM +0100, Jean-Noël Rouvignac (ForgeRock) wrote:
> 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
On Thu, Mar 18, 2021 at 08:57:19AM +0100, Fritz Elfert wrote:
> 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
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
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
12 matches
Mail list logo
