On Tue, 26 Feb 2019 at 09:32, Vladimir Sitnikov <[email protected]> wrote: > > sebb> How are you going to prove that the Gradle functionality is > sufficient? > > Are you aware of https://en.wikipedia.org/wiki/Rice%27s_theorem ? > > Rice> all non-trivial, semantic properties of programs are undecidable
So why bother with any unit tests? > One can't really prove anything about Gradle build. > Note: in exactly the same way, Ant build is not provable either. The Ant build has been proved by long use. The Gradle build needs to generate equivalent outputs for the various functions, otherwise it is not a valid replacement. > > > I don't really get feedback on Gradle, > > > sebb> No idea what that means. > > Look: > 1) I have a Gradle-based build that loads into IDE, and that does run some > of the tests (e.g. :src:components 265 tests completed, 11 failed, 1 > skipped) > 2) I might need to put adjustments here and here, however the build code is > pretty much complete In your opinion. But this needs to be repeatable by others. > That means now it is a good time to try gradle build script and/or provide > feedback if the code opens in IDE, if it builds, if it runs, etc. > > 3) Of course "Maven pom" generation is missing (and other release-related > steps), however I don't really see why everybody else should wait for "100% > feature complete Gradle script" before trying it out. Of course people can try it out at any stage. However it's not valid as a replacement for Ant until it can be shown to provide all the necessary functionality. That seems self-evident to me. > What I see is theoretical discussions like "oh, is Gradle capable of > downloading JavaFX?" > Of course it can be configured to download whatever we need. My question about JavaFX was rather different: > sebb> As already noted, voting is not the same as testing. > > I do whatever testing I think it is worth doing, and I leave the door open > for the ones who care to execute extra tests. I think you need to publish the tests so others can run them and extend them as necessary. We would not accept a patch where the author said they had run unit tests but would not provide them. > The rest are assumed to agree with the change. That's not how such changes should work. > sebb>Gradle can surely be configured to work with the current directory > layout > > It can. Then please do so. > At the same time, it makes no sense to follow that route. I have explained several times why it is sensible. > Vladimir> sebb>Get the Gradle build working with the current layout. > Vladimir> > Vladimir> That's what I always follow. > sebb> AFAICT the Gradle build you are proposing requires lots of changes to > sebb>file locations. > > I'm afraid, I quoted the wrong sentence. > My intention was to quote as below: > > sebb> Don't change more than is absolutely necessary. > > That's what I always follow. > > I do move files around, and I do that for a good reasons (e.g. see items > under "provides several improvements"). > I try to move as little as it is possible, however my primary goal is build > sanity, while "keeping file layout" is not the top priority. Sorry, but that is not the minimum change needed to prove the Gradle build. We would not accept a patch that introduced new code and also changed large amounts of indentation and space trimming at the same time. > Vladimir
