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....
WDYT? Konrad > On 3. Aug 2020, at 12:12, Robert Munteanu <[email protected]> wrote: > > On Fri, 2020-07-31 at 10:56 +0200, Konrad Windszus wrote: >> Hi, >> currently the check-release.sh ( >> https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh) >> executes the Maven build in step 6. with "mvn clean verify". >> >> That means if one releases couples multiple dependent modules one has >> to install the dependent module in the local Maven repository ( >> https://lists.apache.org/thread.html/rc2dad58b0f6817ccadc77ec8fe09b47b9a1c22505e90dd523df70617%40%3Cdev.jackrabbit.apache.org%3E >> ) or reference them from the staging repository. >> >> The latter requires adjusting the pom.xml (passing something like >> "maven.repo.remote" is no longer supported with Maven2+). The former >> requires adding those to the local repo. >> As installing to the local repo is less effort and doesn't >> require passing the staging repository to check-release.sh I would >> propose to adjust step 6 in check-release.sh to execute "mvn clean >> install" instead of "mvn clean verify" > > I think using `mvn clean install` should be OK, as we should not reuse > version numbers between releases. > > As an alternative, we can create a reactor pom on the fly that > aggregates multiple artifacts under vote. That should work for most > scenarios, with the exception of depending on a Maven plug-in from a > reactor. > > Thanks, > Robert
