3. Mission statement Developers typically employ at least three tools: Code editor; Project structure manager (modules, dependencies and compilation options); Build system In the Java world, the first two are typically handled by the IDE (Eclipse, IntelliJ IDEA etc.) The build system is typically separate, and requires duplicating the project structure in the form of Ant or Maven scripts
4. Mission statement Keeping two different project structure definitions means: Duplication of effort; Manual synchronization is error-prone; Synchronization issues are often subtle, hard to detect and resolve ant-intellij-tasks is an open source (Apache license) build system which complements IntelliJ IDEA and builds on its project structure.
5. Architecture ant-intellij-tasks comprises three components: ant-intellij-tasks.jar - Extends Ant with IntelliJ-IDEA-related tasks common.xml - Provides common functionality (e.g. “build module”, “test module” etc.) build-all.xml: A project-wide build script Typically these three are enough to enable automated builds with no further customizations
6. Architecture ant-intellij-tasks.jar is an Ant task library primarily capable of: Parsing project (.ipr) and module (.iml) files Resolving module build order Per-module resolution of: Source/test directories Source/test output paths (relative, absolute or project-inherited) Classpath Resources
7. Architecture common.xml implements the four classic build targets: Clean module output Build module – currently only Java is supported Package module - currently only JARs and WARs are supported Test module – currently only with JUnit. Test classes must follow the convention *Test.java, *Tests.java or Test*.java)
8. Architecture build-all.xml extends the module targets to the entire project Entire codebase can be built with one command:ant –f build-all.xml package Modules are resolved and processed in the correct build order A module can override the default behavior by providing its own build.xml
9. Customization Typically the build is “customized” by tweaking the project settings within IntelliJ IDEA It may, however, be necessary to additionally customize the build process Typically this is done by adding a custom build.xml to a module directory The four targets (clean, build, test, package) are then delegated to the custom script Set the project-file property to the project file location Override by defining a new target with the same name Call the default script using<antcall target=“common.target” />
10. Customization: Tests Maximum heap size can be set with the junit.maxmemory property. (The default is defined by junit.maxmemory.default) Pass system properties by prefixing junit.propertiesto the system property name <?xml version="1.0" encoding="UTF-8"?> <project> <import file="../libraries/ant/common.xml" /> <target name="test"> <property name="project-file" location="../Delver.ipr" /> <property name="junit.properties.lucene.version" value="2.9-dev" /> <property name="junit.maxmemory" value="128m" /> <antcall target="common.test" /> </target> </project>
11. Customization: Limitations ant-intellij-tasks was designed to resolve IntelliJ IDEA metadata files, and leave most of the heavy lifting to Ant Due to time constraints, this design goal is not always met: Global libraries are not supported Packaged JARs and WARs cannot only be customized by tweaking the packaging instructions or manually manipulating the output
12. What’s next? Cleanup Better script documentation Better JavaDocs Significant work on test corpus Apache license headers Testing on Linux Optimization Caching parsed modules/projects Reusing build artifacts if they’re up-to-date Reusing build artifacts for packaging
13. Questions, comments and groans are welcome! Visit the project page at http://code.google.com/p/ant-intellij-tasks/ or send feedback directly to tomer@tomergabel.com