Build Tools - who how what when

From WikiEducator
Jump to: navigation, search

Build Tools: who, how, what, when / A quick useful working build, CI Techniques
Convenor: Andres, Kon
  • Rabea
  • Marc
  • Jesper
  • ...
  • Consistency between central builds and local IDEs is very important
  • Almost everybody has used Maven at some time/project so far
    • In big ecosystems it's not easy to change the buildsystem
  • other build tools introduced ....
  • Gradle
    • Gradle honours Maven and Ivy conventions
    • Assume's their property files and has its own
    • Convince your PM/project lead. Switching over Maven to Gradle (3 dev days? - maybe double as thats a dev estimate ;-))
  • Licensing of jars in your repository was discussed. Many orgs are sensitive to licensing and want to control which jars appear. The license tags in a maven pom aren't used in a consistent manner to be relied upon.
  • pick a (build) tool thats extensible
  • Don't use a homemade tool.
    • Although offers good functionality, what if one in your team maintaining the tool goes on leave?
    • More importantly, if u get a build fail, is it the homegrown build tools
  • Maven Tycho for eclipse RCP/RAP builds with Manifest first mode
  • Look at wharf by Artifactory (JFrog)
    • Ivy is no longer maintained
    • Artifactory guys created Wharf to extend ivy
  • - Gerrit for code reviews
  • Team City - Jetbrains tool for Continuous Integration.
    • Features pre-tested commit so you can run the build on the CI agent without doing an VCS commit.
    • Easy to use AJax UI
  • Move your build away from a tool entirely and use what comes with the IDE. Eg Jetbrains project built by teamcity will ensure the build works the same in CI as it does on dev machine