1. Build Systems Presentation December 14, 2015 Noon-1pm Kathy Lee Simunich Bldg. 203/ D120 https://bluejeans.com/927663739 Brought to you by: Argonne Java Users Group Blogs.anl.gov/java/membershipform

2. From Make to Gradle GNU Make Originally for building C/C++, Fortran (compiled and linked languages) Platform specific builds (need Autoconf) Apache Ant Originated to build Tomcat in early 2000’s Apache Maven Originated from Jakarta Alexandria project 2001 Gradle (gradle.org) Build automation from command line to IDE to Continuous Integration

3. Apache Ant Implemented in Java, best suited for building java projects Built into IDEs for running build scripts Uses XML to describe the build process Platform-independent tool (unlike Make) Integrates JUnit testing in the build process Ant is not good with complex programming constructs: need to write extension tasks in Java for more more complex build logic or GUIs Must build in explicit target dependencies – including all jarfiles and their dependencies Apache Ivy addition to provide jar dependency management in 2007

4. Dependency Management with Whereas Ant makes developers to specify every target/task, Maven was designed to standardized common project/build life- cycles MavenCentral is a code repository for almost all open source jar files. Instead of having copies of say, Xerces, in every one of your Java projects, Maven will automatically download your dependent jar file PLUS any jars that jar is dependent upon – saving space in your SVN/Git repository, as it is stored in a common dir that your IDE points to so that the jar is shared across projects (~/.m2) This also helps with version management, as the dependency tree specifies version as part of the process (artifacts)

5. Maven Control of the Life Cycle Based on the Project Object Model (pom.xml) and guidelines for “best practices” Shared plugin repository Dependencies are defined: groupId (organization), artifactId (name of the jar/project), version. Goals are defined (instead of targets) Unified directory structure: src/main/java, src/main/resources src/test/java, src/test/resources Build artifacts in target directory

6. Using Maven Included in Eclipse IDE (m2): POM editor, Maven project nature, m2 Run Configuration Can specify plugins for compilers, reporting, and code generation. Limitations include rather strict project setup, difficult to extend/write plugins, still uses XML as the build “language”

7. Joins the Scene Created in 2009, built upon the good parts of ant and maven Defaults to Maven’s file structure, but easily modified Accesses Maven repositories for jar dependencies (or any public or local maven repository). Jars are downloaded in ~/.gradle and sharable across projects Downloads the source jar (if included) for debugging No mo’ XML: gradle.build file is a Groovy-based Domain Specific Language (DSL) Plugins for JVM-based languages (Java, Groovy, Scala)

8. Using Eclipse gradle plugin needs to be installed – may or may not need command line. Gradle plugins for java, eclipse and wtp set up the eclipse environment or eclipse web tool project files (.project,.classpath, web.xml) Introduces “scope” to the dependencies (jar needed for testing vs compile vs runtime) Can call any ant task (integrated into gradle) and reuse any ant build file. Most common tasks are built-in. Build tool of choice for Android projects Can extend tasks with inline groovy code, so no need for external task coding Integrates build life cycle tools (e.g Jenkins, JBoss, github, amazon web services, hadoop)