Hi Konrad,

On Mon, 2026-10-12 at 12:48 +0200, Konrad Windszus wrote:
> Hi Robert,
> Is the caching feature of it much different from what can be achieved
> with
> https://maven.apache.org/extensions/maven-build-cache-extension/?
> I would appreciate an open source solution over a commercial one
> (even if provided for free to ASF).


There are two main differences:

1. Develocity reuses intermediate results ( module + goal = cache key
), while the Maven cache extension reuses modules. This means that in
certain cases Develocity has more cache hits

2. Develocity has build insights available OOTB, the Maven build cache
extension is by design smaller in scope.

Of course, onboarding to Develocity is simpler as it's a service while
we would need to manage the cache backend for the Maven build cache
extension.

Thanks,
Robert

> Konrad
> 
> > On 12. Oct 2026, at 10:13, Robert Munteanu <[email protected]>
> > wrote:
> > 
> > Hi,
> > 
> > I am at Community over Code this week and I spoke with the
> > Develocity
> > team. They have a solution for accelerating builds which relies on
> > caching build results that looks interesting for Oak (and
> > Jackrabbit as
> > well).
> > 
> > Their solution is a Maven extension ( so a drop-in configuration to
> > the
> > .mvn/ directory in the root folder ) that configures a cache based
> > on
> > the module + goalĀ  (roughly speaking). For example, a a PR to oak-
> > store-document would not re-run the oak-segment-tar tests.
> > 
> > Their solution is free for ASF projects and you can get see it at
> > [1].
> > It exposes a lot of data about builds and might be useful just for
> > that
> > alone.
> > 
> > Is this something that would be interesting for the
> > Jackrabbit/Oak/FileVault builds?
> > 
> > Onboarding should be very simple and I am in direct contact with
> > the
> > team so if we decide we want to try this out I can expedite the
> > process.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Robert
> > 
> > 
> > [1]: https://develocity.apache.org/
> > 

Reply via email to