You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Konrad Windszus <ko...@gmx.de> on 2020/07/31 08:56:05 UTC
Adjustments of check-release.sh for multi module releases
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"
WDYT?
Thanks for your input,
Konrad
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
Re: Adjustments of check-release.sh for multi module releases
Posted by Robert Munteanu <ro...@apache.org>.
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 Konrad Windszus <ko...@gmx.de>.
FTR: The other option of mingling with your remote repos is outlined at https://maven.apache.org/guides/development/guide-testing-releases.html#guide-to-testing-staged-releases <https://maven.apache.org/guides/development/guide-testing-releases.html#guide-to-testing-staged-releases>
> On 31. Jul 2020, at 10:56, Konrad Windszus <ko...@gmx.de> 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"
>
> WDYT?
>
> Thanks for your input,
> Konrad
>
>
Re: Adjustments of check-release.sh for multi module releases
Posted by Julian Reschke <ju...@gmx.de>.
Am 31.07.2020 um 15:32 schrieb Konrad Windszus:
>
>> On 31. Jul 2020, at 15:29, Julian Reschke <julian.reschke@gmx.de
>> <ma...@gmx.de>> wrote:
>>
>> Q: so why does this work when we do multi-module releases in Jackrabbit
>> Classic or Oak?
>
> This is not about one Maven reactor build (which might obviously contain
> as many modules as you would like) but about two or more modules which
> are not(!) part of the same reactor.
Aha, so in case of a reactor build, the sibling modules are found
despite not being installed. Thanks for clarifying.
Going back to your suggestion: I don't believe we should change the
default behavior of check-release, because installing the thing being
voted on might have negatife effects.
I'm not sure how frequently this is needed, but just putting the "right"
instructions to execute into the vote mail would IMHO be sufficient.
Best regards, Julian
Re: Adjustments of check-release.sh for multi module releases
Posted by Konrad Windszus <ko...@gmx.de>.
> On 31. Jul 2020, at 15:29, Julian Reschke <ju...@gmx.de> wrote:
>
> Q: so why does this work when we do multi-module releases in Jackrabbit
> Classic or Oak?
This is not about one Maven reactor build (which might obviously contain as many modules as you would like) but about two or more modules which are not(!) part of the same reactor.
Re: Adjustments of check-release.sh for multi module releases
Posted by Julian Reschke <ju...@gmx.de>.
Am 31.07.2020 um 10:56 schrieb Konrad Windszus:
> 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"
>
> WDYT?
The downside is that the user might end up with a local artefact that
will not be released, or even worse, might get released with different
contents.
This might be fixable by modifiying settings.xml and adding a profile
(but probably wouldn't fly because we don't want people to have to mess
around with their condig).
Q: so why does this work when we do multi-module releases in Jackrabbit
Classic or Oak?
Best regards, Julian