Gilles, > I do _not_ ask any work to be done in order to complicate the release > process and/or review. > My question was (cf. above and the other thread) whether singling out > the "examples" module has any benefit (apart from saving a few bytes > on Maven Central).
Yes, I believe it is beneficial. If nothing else, it keeps maven central and the project site uncluttered and reduces the chance of user confusion. -Matt J On Thu, Aug 5, 2021 at 12:50 PM Alex Herbert <alex.d.herb...@gmail.com> wrote: > > On Thu, 5 Aug 2021 at 17:23, Gilles Sadowski <gillese...@gmail.com> wrote: > > > Hi. > > > > Le jeu. 5 août 2021 à 18:01, Alex Herbert <alex.d.herb...@gmail.com> a > > écrit : > > > > > > On Thu, 5 Aug 2021 at 14:07, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > > Le jeu. 5 août 2021 à 14:08, Gary Gregory <garydgreg...@gmail.com> a > > > > écrit : > > > > > > > > > > I agree with Matt. > > > > > > > > Nobody seems to disagree (about not providing convenience *binaries* > > > > of the examples). > > > > My point was that the examples _must_ be part of the (source) release > > > > (with the caveat that they are not subject to BC), in the same way that > > > > unit tests are, because they could sometimes exercise the code in a way > > > > which the unit tests do not. > > > > Maybe I misunderstood Matt's proposal, which I thought was was to not > > > > release the examples (i.e. leaving them out of the release branch). > > > > > > > > > > If the release profile in the POM omits the examples modules then they > > will > > > not be released as binary jars to nexus, and the modules are omitted from > > > the site generation. The contents of the distribution release binary > > (zip, > > > tar.gz) are specified separately. So these can include all the source > > text > > > files from the examples. > > > > > > However if the examples modules are not in the POM hierarchy then the > > > binaries will not be built from the source as part of the release > > process. > > > It is possible to include the modules and skip the site generation for > > the > > > maven-site-plugin. I am not sure about skipping the maven-release-plugin. > > > It may be possible using the dryRun parameter but I would have to > > > investigate. > > > > > > If the build of the examples cannot be set-up to be verified during the > > > release process then this should be verified by the RM and any reviewers > > of > > > the release to ensure the examples do build from the source distribution. > > > > > > In the case of RNG this could involve adding a step to the release guide > > to > > > state that applications in all the example modules should be run to > > ensure > > > they compile with the API from the released code. The same can be added > > to > > > guidelines in the VOTE e-mail. > > > > > > Would this cover your requirement that the examples code is exercised? > > > > I do _not_ ask any work to be done in order to complicate the release > > process and/or review. > > My question was (cf. above and the other thread) whether singling out > > the "examples" module has any benefit (apart from saving a few bytes > > on Maven Central). > > > > I've just pushed an update to RNG to add more details on how to run the > examples. I will look at preparing a release without the examples modules > in the next few days. Ideally I would like to ensure the process builds the > binaries just to check it is possible but not add them Maven central or the > limited module reports to the site. Otherwise I am fine with a manual > verification step (that can be scripted) just to build and run each example. > > The examples are built using Jenkins so they should be kept current and > able to compile. Running them is not something done by the CI build. > > Alex > > > > > > > Best, > > Gilles > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
