+1 from me on Gradle. The advantages in having very fast (and correct) incremental builds are very nice.
I wouldn't expect major problems in setting up for Apache releases since several other ASF projects are already using it. Based on feedback on this, I'd also like to later start a similar Gradle proposal for Pulsar builds too. Matteo On Tue, Nov 10, 2020 at 3:08 AM Enrico Olivelli <eolive...@gmail.com> wrote: > > Il giorno mar 10 nov 2020 alle ore 11:09 Ivan Kelly <iv...@apache.org> ha > scritto: > > > Hi folks, > > > > It's been about a year since Streamlio joined Splunk and since then > > we've had a bit of forking with our BK branch. > > It has gotten to a stage where it's starting to be a problem for us, > > so we'd like to start to get things back in sync. > > > > There are a couple of big chunks of work to come back. > > We've added a data integrity checker that replaces a lot of the > > functionality of autorecovery and allows us to run without a journal. > > We refactored the bookie to allow dependency injection. > > We've rewritten the entry logger to use direct I/O (allowing 2GBps > > writes per bookie). > > > > Cool, eager to see those changes in ASF BK > > > > > > One other thing we've done is to change the build system to use gradle. > > The major driver for this was that maven is just slow, even before you > > start running tests. > > "mvn clean package -DskipTests" takes 4m30 on my laptop. "./gradlew > > clean jar" takes 40s. > > Subsequent builds on gradle are much much faster, as it does > > incremental building. > > Incremental building exists in maven, but it doesn't work. > > Gradle also handle multimodule projects better. If I make a change in > > bookkeeper-common, > > "./gradlew :bookkeeper-server:test" will pick up the change without > > having to explicitly > > "mvn install" the bookkeeper-common. In my opinion it's just a much > > nicer build system > > to work with. Even the poms it generates are better as they avoid > > dependency pollution. > > > > I am not a big fan of Gradle, but I don't want to start a battle. There are > pros and cons. > To me it is a matter of taste, both of the two worlds are pretty widespread. > Personally I have experienced the move of some projects from Maven to > Gradle with a little bit of pain, > but as said I am not against a change. > > Usually changing the build system is problematic for: > - existing contributors/committers > - forked repositories > > If you have time and resources to drive the change and to help the > community to understand how to work with Gradle I am happy to accept it. > I will be also a good change to reduce some tech debt, when you rewrite the > build system/configuration you can decide to chop useless stuff that you > aren't dropping because it is better to not fix things that aren't broken > So +1, a BP is a good starting point please > > > > What are peoples opinions on moving BookKeeper to gradle (assuming > > I/splunk do the legwork)? > > If people are open to it, I'll submit a BP. > > > > Another thing that BK (and the whole ecosystem) is missing is > > structured logging. > > We also plan to add structured logging to BK in soon. This is a major > > motivator for converging the branches, > > as it touches a lot of places. > > > > +1 > > > > Anyhow, any feedback appreciated. > > > > I am happy that the community can start to work together again as a whole > > Enrico > > > > > > -Ivan > >
