Hey, build stuff! My niche! So...make or Gradle are my two thoughts. Maven is a shitty option for anything but Java. Make is old school and all, but it Just Does What It Says It Will, which is nice. Gradle is, IMHO, problematic for Java projects due to how easy it is to due weird non-standard things with it, but in this case, we are kinda looking for exactly that. So.
One advantage to Gradle is that it does Java builds. Because if we have to build Java, we are going to end up invoking Maven or Gradle (or, shudder, Ant) eventually anyway, whether we are building with Make or Gradle or whatever. So cutting out the middleman has virtue. On Wednesday, September 23, 2015, Allen Wittenauer <[email protected]> wrote: > > Hey hey hey. > > One of the big decisions that needs to be made relatively quickly > is what sort of build tool layout we want to have for the various > components. Sean and I have been discussing this topic I think for > probably a month now but never came to any firm decision. [This is > particularly relevant to YETUS-2, YETUS-6 and YETUS-15.] Let me see if I > can summarize all of the highlights… I’m sure Sean will add whatever I > forgot. :) > > * It’s extremely important that we be able to test Yetus with Yetus ASAP. > (I hope this is obvious… *smile*) > > * Given our multi-lingual needs (Java, python, & bash as of today), > different components may need different build tools. > > * Avro is a lesson of what happens when there are too many independent > build systems. > > * Today, Yetus does not support multiple build tools in a single project > easily or perhaps at all. [That’s a future project. ;) ] > > * One of the founding principals is to keep things as highly portable as > possible. This indicates ‘make’ or a common derivative (e.g., autoconf) as > highly desirable. Plus there is a good chance that the Yetus community at > large is going to be more familiar with make over every other tool. > > * Recursive building is a huge …. but is an anti-pattern in make. > > * Today, Yetus has support for ant, gradle, and maven, with maven support > being the strongest and gradle support being the weakest (things like > checkstyle are just flat out not supported yet). Adding support for make > is on the list but not there yet. > > * Maven is likely to be the ‘fastest’ for us to bootstrap and be > productive with: annotations already has a pom, we already know how to do > bats-based unit testing for the bash code, mvn site support, recursion, > etc, etc. But longer term, it may not be the ‘best’ solution and the > learning curve for folks is particularly high. So there might be an > (expensive) build tool switch later on. > > * There is still the whole “what does a release artifact look like?” > discussion that will likely have an impact on the build tool. But that > should be a relatively minor concern. I hope. > > * Who has the cycles to build the build bits anyway? > > > Anyone have any thoughts? Opinions? Thanks! > >
