| Build Tools: who, how, what, when / A quick useful working build, CI Techniques
|
| Convenor: Andres, Kon
|
| Participants:
|
Summary:
- 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.
|
Recommendations:
- 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
- http://code.google.com/p/gerrit - 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
|
|
|
