You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Benjamin Marwell <bm...@apache.org> on 2023/06/12 08:52:56 UTC
Questions about the build cache plugin
Hello everyone!
First of all thank you everyone working on the build cache plugin! It
is amazing!
At least some of the following questions seem to be of interest to
most users and might end up on the documentation, So here's a few
things which came to my mind.
1.) Considering I always require PRs in my projects, would setting
-Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
for the main branch?
2.) Can I maybe have the branch name included in a path to a remote?
This way I could have a different cache for maintenance branches. Just
include the branch name into -Dmaven.build.cache.remote.url?
3.) Can I somehow use option 1 & 2 to make caches available for
colleagues without making them manually configure the remote URL for
each branch they are working on?
4.) The docs say there's also XX and XXMM algorithms, but it doesn't
say WHEN to use them (only that they may leverage performance). Are
there some example cases or does someone already have some experience
we could benefit from?
5.) The section "filtering out artifacts" might want to give a size of
artifacts which should be regarded as too large, depending on the
environment probably.
Thanks!
- Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Questions about the build cache plugin
Posted by Xy Dav <fa...@gmail.com>.
_Dmaven build cache.remote.save.anabled=türü
Bütün yetki sende
12 Haz 2023 Pzt 13:08 tarihinde Olivier Lamy <ol...@apache.org> şunu yazdı:
> On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org>
> wrote:
> >
> > Hello everyone!
> >
> > First of all thank you everyone working on the build cache plugin! It
> > is amazing!
> >
> > At least some of the following questions seem to be of interest to
> > most users and might end up on the documentation, So here's a few
> > things which came to my mind.
> >
> > 1.) Considering I always require PRs in my projects, would setting
> > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > for the main branch?
>
> Personally, I would have the main branch always have a full build
> without caching to be sure everything works fine but use cache only
> for branches/PR :)
> That's what we will do at Jetty project.
> The build for 12 branch is around 50 minutes with the cache it goes
> down to 8/9 minutes (only because something is always rebuilt and
> retrigger a few small modules)
> The idea is to reduce development/check of PR and use some incremental
> build while the main is always fully build especially when the build
> has few jdks as target.
> But here it's up to you :)
>
> >
> > 2.) Can I maybe have the branch name included in a path to a remote?
> > This way I could have a different cache for maintenance branches. Just
> > include the branch name into -Dmaven.build.cache.remote.url?
>
> why would need that?
> if your branch has different sources (java, pom, etc..) the calculated
> hash will be different so the hash key will be simply different no
> need to configure a cache URL differently (well except if you want to
> clean up caches per branch)
>
> >
> > 3.) Can I somehow use option 1 & 2 to make caches available for
> > colleagues without making them manually configure the remote URL for
> > each branch they are working on?
>
> cache will be used by colleagues' build as long as a module have the
> same calculated hash any local differences will have a different
> calculated hash
>
> >
> > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > say WHEN to use them (only that they may leverage performance). Are
> > there some example cases or does someone already have some experience
> > we could benefit from?
>
>
> I have yet to see huge differences.
> currently with a build already down from 50 minutes to 8/9 minutes not
> sure this was my primary goal
> So I can't really tell :)
>
> >
> > 5.) The section "filtering out artifacts" might want to give a size of
> > artifacts which should be regarded as too large, depending on the
> > environment probably.
> >
>
> definitely depends on your environment.
>
> > Thanks!
> > - Ben
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Questions about the build cache plugin
Posted by Olivier Lamy <ol...@apache.org>.
On Sat, 17 Jun 2023 at 11:05, Hervé Boutemy <he...@free.fr> wrote:
>
> reading the discussion about maintenance branch and "who updates the cache", I
> think that:
>
> 1. maintenance branch is like main branch: with Olivier's nice strategy, you
> should build fully. In fact, the few long-lived branches should be built
> fully, only the many PR short-lived branches should be built quickly with
> cache
When I mean build fully for main branches, I mean only on CI but
locally the local cache is used on dev machine.
>
> 2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT,
> ie the last publication wins over previous ones. With cache, any publication
> is just an addition of new content, indexed by input checksums. Then we don't
> really care about who is the first discovering a new input checksum, then
> filling the output cache for that new input checksum.
>
> Really nice feedback on build cache extension in real life!
>
> Thanks a lot to the contributor to this great feature
>
> Regards,
>
> Hervé
>
> Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit :
> > On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell <bm...@gmail.com> wrote:
> > > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy
> <ol...@apache.org>:
> > > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org>
> wrote:
> > > > > Hello everyone!
> > > > >
> > > > > First of all thank you everyone working on the build cache plugin! It
> > > > > is amazing!
> > > > >
> > > > > At least some of the following questions seem to be of interest to
> > > > > most users and might end up on the documentation, So here's a few
> > > > > things which came to my mind.
> > > > >
> > > > > 1.) Considering I always require PRs in my projects, would setting
> > > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > > > > for the main branch?
> > > >
> > > > Personally, I would have the main branch always have a full build
> > > > without caching to be sure everything works fine but use cache only
> > > > for branches/PR :)
> > > > That's what we will do at Jetty project.
> > > > The build for 12 branch is around 50 minutes with the cache it goes
> > > > down to 8/9 minutes (only because something is always rebuilt and
> > > > retrigger a few small modules)
> > > > The idea is to reduce development/check of PR and use some incremental
> > > > build while the main is always fully build especially when the build
> > > > has few jdks as target.
> > > > But here it's up to you :)
> > >
> > > I can see your point, but who is updating the remote cache then?
> >
> > every PR potentially updates the cache. depending on changes per PR
> > some module cache will be shared or not with other PRs.
> > We (Jetty project) have decided to not have any publicity open remote
> > cache setup per default as we do not have the infra for this (but CI
> > use a private one)
> > but in a company context or if you have the infra for this it might be
> > a better option.
> >
> > > > > 2.) Can I maybe have the branch name included in a path to a remote?
> > > > > This way I could have a different cache for maintenance branches. Just
> > > > > include the branch name into -Dmaven.build.cache.remote.url?
> > > >
> > > > why would need that?
> > > > if your branch has different sources (java, pom, etc..) the calculated
> > > > hash will be different so the hash key will be simply different no
> > > > need to configure a cache URL differently (well except if you want to
> > > > clean up caches per branch)
> > >
> > > It depends on what you might be trying to do. For projects with new
> > > major versions and some
> > > big refactoring done in the past, this did sound sensible to me.
> > > What is the cache worth if there's 0% hit on the maintenance branch?
> >
> > hit ratio will depend on the changes you do.
> > parent pom change -> everything will be rebuilt
> > single java source in a module: only this module and dependant will be
> > rebuilt. Finally, there is no single rule on how to use/configure the
> > cache, the usage depends on how a team is working, what sort of change they
> > often have, etc...
> > first, have your build working (if it's complicated one you may have
> > some extra configuration to add)
> >
> > > > > 3.) Can I somehow use option 1 & 2 to make caches available for
> > > > > colleagues without making them manually configure the remote URL for
> > > > > each branch they are working on?
> > > >
> > > > cache will be used by colleagues' build as long as a module have the
> > > > same calculated hash any local differences will have a different
> > > > calculated hash
> > >
> > > Same as above:
> > > What about devs working on a maintenance branch when main has seen big
> > > refactoring?
> > >
> > > > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > > > > say WHEN to use them (only that they may leverage performance). Are
> > > > > there some example cases or does someone already have some experience
> > > > > we could benefit from?
> > > >
> > > > I have yet to see huge differences.
> > > > currently with a build already down from 50 minutes to 8/9 minutes not
> > > > sure this was my primary goal
> > > > So I can't really tell :)
> > >
> > > Well, it is listed under "performance tuning", so I concluded it might
> > > make a difference.
> > > Will probably go for XX (because it is mentioned as performance tuning
> > > without any drawbacks)
> > >
> > > and switch to Metro once it is there.
> > >
> > > > > 5.) The section "filtering out artifacts" might want to give a size of
> > > > > artifacts which should be regarded as too large, depending on the
> > > > > environment probably.
> > > >
> > > > definitely depends on your environment.
> > >
> > > Yup.
> > > I might use different settings in a corporate environment, my thought.
> > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Questions about the build cache plugin
Posted by Hervé Boutemy <he...@free.fr>.
reading the discussion about maintenance branch and "who updates the cache", I
think that:
1. maintenance branch is like main branch: with Olivier's nice strategy, you
should build fully. In fact, the few long-lived branches should be built
fully, only the many PR short-lived branches should be built quickly with
cache
2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT,
ie the last publication wins over previous ones. With cache, any publication
is just an addition of new content, indexed by input checksums. Then we don't
really care about who is the first discovering a new input checksum, then
filling the output cache for that new input checksum.
Really nice feedback on build cache extension in real life!
Thanks a lot to the contributor to this great feature
Regards,
Hervé
Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit :
> On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell <bm...@gmail.com> wrote:
> > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy
<ol...@apache.org>:
> > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org>
wrote:
> > > > Hello everyone!
> > > >
> > > > First of all thank you everyone working on the build cache plugin! It
> > > > is amazing!
> > > >
> > > > At least some of the following questions seem to be of interest to
> > > > most users and might end up on the documentation, So here's a few
> > > > things which came to my mind.
> > > >
> > > > 1.) Considering I always require PRs in my projects, would setting
> > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > > > for the main branch?
> > >
> > > Personally, I would have the main branch always have a full build
> > > without caching to be sure everything works fine but use cache only
> > > for branches/PR :)
> > > That's what we will do at Jetty project.
> > > The build for 12 branch is around 50 minutes with the cache it goes
> > > down to 8/9 minutes (only because something is always rebuilt and
> > > retrigger a few small modules)
> > > The idea is to reduce development/check of PR and use some incremental
> > > build while the main is always fully build especially when the build
> > > has few jdks as target.
> > > But here it's up to you :)
> >
> > I can see your point, but who is updating the remote cache then?
>
> every PR potentially updates the cache. depending on changes per PR
> some module cache will be shared or not with other PRs.
> We (Jetty project) have decided to not have any publicity open remote
> cache setup per default as we do not have the infra for this (but CI
> use a private one)
> but in a company context or if you have the infra for this it might be
> a better option.
>
> > > > 2.) Can I maybe have the branch name included in a path to a remote?
> > > > This way I could have a different cache for maintenance branches. Just
> > > > include the branch name into -Dmaven.build.cache.remote.url?
> > >
> > > why would need that?
> > > if your branch has different sources (java, pom, etc..) the calculated
> > > hash will be different so the hash key will be simply different no
> > > need to configure a cache URL differently (well except if you want to
> > > clean up caches per branch)
> >
> > It depends on what you might be trying to do. For projects with new
> > major versions and some
> > big refactoring done in the past, this did sound sensible to me.
> > What is the cache worth if there's 0% hit on the maintenance branch?
>
> hit ratio will depend on the changes you do.
> parent pom change -> everything will be rebuilt
> single java source in a module: only this module and dependant will be
> rebuilt. Finally, there is no single rule on how to use/configure the
> cache, the usage depends on how a team is working, what sort of change they
> often have, etc...
> first, have your build working (if it's complicated one you may have
> some extra configuration to add)
>
> > > > 3.) Can I somehow use option 1 & 2 to make caches available for
> > > > colleagues without making them manually configure the remote URL for
> > > > each branch they are working on?
> > >
> > > cache will be used by colleagues' build as long as a module have the
> > > same calculated hash any local differences will have a different
> > > calculated hash
> >
> > Same as above:
> > What about devs working on a maintenance branch when main has seen big
> > refactoring?
> >
> > > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > > > say WHEN to use them (only that they may leverage performance). Are
> > > > there some example cases or does someone already have some experience
> > > > we could benefit from?
> > >
> > > I have yet to see huge differences.
> > > currently with a build already down from 50 minutes to 8/9 minutes not
> > > sure this was my primary goal
> > > So I can't really tell :)
> >
> > Well, it is listed under "performance tuning", so I concluded it might
> > make a difference.
> > Will probably go for XX (because it is mentioned as performance tuning
> > without any drawbacks)
> >
> > and switch to Metro once it is there.
> >
> > > > 5.) The section "filtering out artifacts" might want to give a size of
> > > > artifacts which should be regarded as too large, depending on the
> > > > environment probably.
> > >
> > > definitely depends on your environment.
> >
> > Yup.
> > I might use different settings in a corporate environment, my thought.
> >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Questions about the build cache plugin
Posted by Olivier Lamy <ol...@apache.org>.
On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell <bm...@gmail.com> wrote:
>
> Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy <ol...@apache.org>:
>
> > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org> wrote:
> > >
> > > Hello everyone!
> > >
> > > First of all thank you everyone working on the build cache plugin! It
> > > is amazing!
> > >
> > > At least some of the following questions seem to be of interest to
> > > most users and might end up on the documentation, So here's a few
> > > things which came to my mind.
> > >
> > > 1.) Considering I always require PRs in my projects, would setting
> > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > > for the main branch?
> >
> > Personally, I would have the main branch always have a full build
> > without caching to be sure everything works fine but use cache only
> > for branches/PR :)
> > That's what we will do at Jetty project.
> > The build for 12 branch is around 50 minutes with the cache it goes
> > down to 8/9 minutes (only because something is always rebuilt and
> > retrigger a few small modules)
> > The idea is to reduce development/check of PR and use some incremental
> > build while the main is always fully build especially when the build
> > has few jdks as target.
> > But here it's up to you :)
>
> I can see your point, but who is updating the remote cache then?
>
every PR potentially updates the cache. depending on changes per PR
some module cache will be shared or not with other PRs.
We (Jetty project) have decided to not have any publicity open remote
cache setup per default as we do not have the infra for this (but CI
use a private one)
but in a company context or if you have the infra for this it might be
a better option.
>
>
> > > 2.) Can I maybe have the branch name included in a path to a remote?
> > > This way I could have a different cache for maintenance branches. Just
> > > include the branch name into -Dmaven.build.cache.remote.url?
> >
> > why would need that?
> > if your branch has different sources (java, pom, etc..) the calculated
> > hash will be different so the hash key will be simply different no
> > need to configure a cache URL differently (well except if you want to
> > clean up caches per branch)
>
> It depends on what you might be trying to do. For projects with new
> major versions and some
> big refactoring done in the past, this did sound sensible to me.
> What is the cache worth if there's 0% hit on the maintenance branch?
>
hit ratio will depend on the changes you do.
parent pom change -> everything will be rebuilt
single java source in a module: only this module and dependant will be rebuilt.
Finally, there is no single rule on how to use/configure the cache,
the usage depends on how a team is working, what sort of change they
often have, etc...
first, have your build working (if it's complicated one you may have
some extra configuration to add)
>
>
> > > 3.) Can I somehow use option 1 & 2 to make caches available for
> > > colleagues without making them manually configure the remote URL for
> > > each branch they are working on?
> >
> > cache will be used by colleagues' build as long as a module have the
> > same calculated hash any local differences will have a different
> > calculated hash
>
> Same as above:
> What about devs working on a maintenance branch when main has seen big
> refactoring?
>
>
> > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > > say WHEN to use them (only that they may leverage performance). Are
> > > there some example cases or does someone already have some experience
> > > we could benefit from?
> >
> > I have yet to see huge differences.
> > currently with a build already down from 50 minutes to 8/9 minutes not
> > sure this was my primary goal
> > So I can't really tell :)
>
> Well, it is listed under "performance tuning", so I concluded it might
> make a difference.
> Will probably go for XX (because it is mentioned as performance tuning
> without any drawbacks)
> and switch to Metro once it is there.
>
>
> > > 5.) The section "filtering out artifacts" might want to give a size of
> > > artifacts which should be regarded as too large, depending on the
> > > environment probably.
> > >
> >
> > definitely depends on your environment.
>
> Yup.
> I might use different settings in a corporate environment, my thought.
>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Questions about the build cache plugin
Posted by Benjamin Marwell <bm...@gmail.com>.
Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy <ol...@apache.org>:
> On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org> wrote:
> >
> > Hello everyone!
> >
> > First of all thank you everyone working on the build cache plugin! It
> > is amazing!
> >
> > At least some of the following questions seem to be of interest to
> > most users and might end up on the documentation, So here's a few
> > things which came to my mind.
> >
> > 1.) Considering I always require PRs in my projects, would setting
> > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> > for the main branch?
>
> Personally, I would have the main branch always have a full build
> without caching to be sure everything works fine but use cache only
> for branches/PR :)
> That's what we will do at Jetty project.
> The build for 12 branch is around 50 minutes with the cache it goes
> down to 8/9 minutes (only because something is always rebuilt and
> retrigger a few small modules)
> The idea is to reduce development/check of PR and use some incremental
> build while the main is always fully build especially when the build
> has few jdks as target.
> But here it's up to you :)
I can see your point, but who is updating the remote cache then?
> > 2.) Can I maybe have the branch name included in a path to a remote?
> > This way I could have a different cache for maintenance branches. Just
> > include the branch name into -Dmaven.build.cache.remote.url?
>
> why would need that?
> if your branch has different sources (java, pom, etc..) the calculated
> hash will be different so the hash key will be simply different no
> need to configure a cache URL differently (well except if you want to
> clean up caches per branch)
It depends on what you might be trying to do. For projects with new
major versions and some
big refactoring done in the past, this did sound sensible to me.
What is the cache worth if there's 0% hit on the maintenance branch?
> > 3.) Can I somehow use option 1 & 2 to make caches available for
> > colleagues without making them manually configure the remote URL for
> > each branch they are working on?
>
> cache will be used by colleagues' build as long as a module have the
> same calculated hash any local differences will have a different
> calculated hash
Same as above:
What about devs working on a maintenance branch when main has seen big
refactoring?
> > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> > say WHEN to use them (only that they may leverage performance). Are
> > there some example cases or does someone already have some experience
> > we could benefit from?
>
> I have yet to see huge differences.
> currently with a build already down from 50 minutes to 8/9 minutes not
> sure this was my primary goal
> So I can't really tell :)
Well, it is listed under "performance tuning", so I concluded it might
make a difference.
Will probably go for XX (because it is mentioned as performance tuning
without any drawbacks)
and switch to Metro once it is there.
> > 5.) The section "filtering out artifacts" might want to give a size of
> > artifacts which should be regarded as too large, depending on the
> > environment probably.
> >
>
> definitely depends on your environment.
Yup.
I might use different settings in a corporate environment, my thought.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Questions about the build cache plugin
Posted by Olivier Lamy <ol...@apache.org>.
On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bm...@apache.org> wrote:
>
> Hello everyone!
>
> First of all thank you everyone working on the build cache plugin! It
> is amazing!
>
> At least some of the following questions seem to be of interest to
> most users and might end up on the documentation, So here's a few
> things which came to my mind.
>
> 1.) Considering I always require PRs in my projects, would setting
> -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only
> for the main branch?
Personally, I would have the main branch always have a full build
without caching to be sure everything works fine but use cache only
for branches/PR :)
That's what we will do at Jetty project.
The build for 12 branch is around 50 minutes with the cache it goes
down to 8/9 minutes (only because something is always rebuilt and
retrigger a few small modules)
The idea is to reduce development/check of PR and use some incremental
build while the main is always fully build especially when the build
has few jdks as target.
But here it's up to you :)
>
> 2.) Can I maybe have the branch name included in a path to a remote?
> This way I could have a different cache for maintenance branches. Just
> include the branch name into -Dmaven.build.cache.remote.url?
why would need that?
if your branch has different sources (java, pom, etc..) the calculated
hash will be different so the hash key will be simply different no
need to configure a cache URL differently (well except if you want to
clean up caches per branch)
>
> 3.) Can I somehow use option 1 & 2 to make caches available for
> colleagues without making them manually configure the remote URL for
> each branch they are working on?
cache will be used by colleagues' build as long as a module have the
same calculated hash any local differences will have a different
calculated hash
>
> 4.) The docs say there's also XX and XXMM algorithms, but it doesn't
> say WHEN to use them (only that they may leverage performance). Are
> there some example cases or does someone already have some experience
> we could benefit from?
I have yet to see huge differences.
currently with a build already down from 50 minutes to 8/9 minutes not
sure this was my primary goal
So I can't really tell :)
>
> 5.) The section "filtering out artifacts" might want to give a size of
> artifacts which should be regarded as too large, depending on the
> environment probably.
>
definitely depends on your environment.
> Thanks!
> - Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org