On Tue, 26 Feb 2019 at 10:14, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > > 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 ?
I was referring to the statement above: > I do whatever testing I think it is worth doing > AFAICT, Vladimir provided the steps to run gradle and he asked for feedback > from us right ? Yes, but AFAICT he implied that he was doing additional tests. > > > 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. Maybe not, but it's not clear to me from what he wrote. > > > > 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 Yes. But such a wall can only be discovered by testing that the Gradle build does what it needs to do. As I already wrote, I think it's unlikely that Gradle will prove unable to provide what we need, but that needs proving. > > > > > 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. I was suggesting that the layout can be changed later. > For example, if we had chosen to move to Maven, we would have modified > layout. Probably, but I think it would have been sensible to change the layout (and fix up Ant) separately. One could then compare Ant with Maven to validate the outputs. > @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 Yes please! > > > > > > 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 > >
