You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Robert Munteanu <ro...@apache.org> on 2020/08/03 10:12:50 UTC
Re: Adjustments of check-release.sh for multi module releases
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
Re: Adjustments of check-release.sh for multi module releases
Posted by Julian Sedding <js...@gmail.com>.
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 <ro...@apache.org> 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
>
Re: Adjustments of check-release.sh for multi module releases
Posted by Robert Munteanu <ro...@apache.org>.
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
Re: Adjustments of check-release.sh for multi module releases
Posted by Konrad Windszus <ko...@gmx.de>.
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 <ro...@apache.org> 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