On Mon, 25 Feb 2019 at 21:22, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > sebb>Get the Gradle build working with the current layout. > > That's what I always follow.
Huh? AFAICT the Gradle build you are proposing requires lots of changes to file locations. > sebb> How do you propose to test that the Gradle build supports all the Ant > functions? > > That's simple: > 1) I'm going to put a > https://www.apache.org/foundation/voting.html#LazyConsensus vote > 2) I assume the vote would pass with a great success, so I (or someone > else) commit the change A vote is not a test. How are you going to prove that the Gradle functionality is sufficient? > Note: we don't really need to support all the Ant functions. Possibly; that remains to be seen. > I'm sure there will be Ant obsolete ant targets (e.g. svnmucc related ones) The svnmucc ones are *not* obsolete; they relate to dist.apache.org which is controlled by Infra. AFAIK dist.a.o will never move from SVN to Git. > sebb>What about staging files? > > What do you mean by staging? Staging to Apache Maven Repository? Staging to dist.apache.org for a release vote. > This and the rest should be handled by Gradle after some configuration. That work still needs to be done, and it needs to be shown to work before cutting over. > sebb>It's the edge cases that tend to catch people out; > > I don't really get feedback on Gradle, No idea what that means. > so I assume we should go with "make test run, make jar sign, etc and then > vote" plan. As already noted, voting is not the same as testing. > I'm sure file movement does not hurt, and I don't really see how discussing > that back and forth helps. Until such time as the build can be cut over, any changes to source files may have to be done in two places. Also, as I already explained, it makes testing harder. Gradle can surely be configured to work with the current directory layout. If not, it's clearly worse than Ant - at least in that respect. > Vladimir
