On Tue, Feb 26, 2019 at 10:57 AM sebb <seb...@gmail.com> wrote: > On Tue, 26 Feb 2019 at 09:32, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> 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. >
And we see it is not perfect And we see Gradle could bring improvements and new developer adoption > The Gradle build needs to generate equivalent outputs for the various > functions, otherwise it is not a valid replacement. > I guess what Vladimir is saying is that Gradle can provide same features in a different way (built-in) Maybe Vladimir you could clarify which built-in feature would be used as a replacement for: - the release related features - the sonar integration features - in summary, all parts you didn't migrate > > > > 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. > I'll try to test it ASAP > > > 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. > I find it reasonable that you, we provide feedback on this PR by testing it in different setups and IDEs. That's what Vladimir is asking for I guess. > > 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. > Which tests ? AFAICT, Vladimir provided the steps to run gradle and he asked for feedback from us right ? > We would not accept a patch where the author said they had run unit > tests but would not provide them. > I don't think that's what Vladimir is saying. > > The rest are assumed to agree with the change. > > That's not how such changes should work. > In previous discussion, I think many of use voted +1 for a move to gradle provided no wall is faced > > > sebb>Gradle can surely be configured to work with the current directory > > layout > > > > It can. > > Then please do so. > Although I agree with sebb that not touching layout makes it easier for us to study and work progressively with this migration. I am not sure we should keep layout AS-IS. For example, if we had chosen to move to Maven, we would have modified layout. @Vladimir Sitnikov <sitnikov.vladi...@gmail.com> is it mandatory to change layout ? What would we loose or have to do additionally if we don't touch it as least in first migration step: - First step IMU being provide all features of current build - Second step would be to change layout if there's a reason for it > > > 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 >
