Hi Combining the empty local repo with a fallback to the "full" local repo can speed things up a lot. I have used this strategy in the past to "fill" minimal customer-specific local repos to enable offline work. That requires a profile and thus a settings.xml, but that should all be scriptable I suppose. The only difficulty could be if someone doesn't have their local repo in the default location.
An alternative to providing a settings.xml could be to set a profile name for the "check"-build and provide documentation on how to configure a profile that uses the local repository as a remote repository for the build. That would allow everyone to op-in to having a fast build while keeping local repositories clean (the temporary local repo would obviously need to be removed after the build). WDYT? Regards Julian On Mon, Aug 3, 2020 at 12:19 PM Robert Munteanu <[email protected]> wrote: > > On Mon, 2020-08-03 at 12:15 +0200, Konrad Windszus wrote: > > We can even leverage a custom (empty) local repo via "- > > Dmaven.repo.local" which can be thrown away after release > > verification. > > That way one would notice references which are no longer available > > publically (for whatever reason). > > That would delay the release check though, as you would need to > > redownload all necessary plugins/dependencies.... > > Hm, that sounds interesting. The question is what is the relative > increaase of the check time. I run the validation in a console and then > switch away since it takes too long to wait for it. > > If it's 10-20% longer I think that's fine. If it's 5x longer it's > probably a no-go. > > Thanks, > Robert >
