Embrace Maven

Editor's Notes

• #2: Welcome to the Embrace Maven session. This presentation is for people who are using maven and want to learn a little more about it in order to be more effective with it.
• #8: Yiddish for “מבין” At the time Maven was created, Ant was the most popular build tool. It was very verbose and it didn’t even have dependency management
• #9: Maven’s philosophy - Convention over configuration = reasonable default behavior. A project that has no special needs can be very easily created. Just put your code under src/main/java and your tests under src/test/java etc.. By doing only that with a pom file you get a project that compiles, tests and packages itself. Opinionated means There’s a way to do stuff Doing stuff the wrong way has consequences
• #12: Three built-in lifecycles - clean, deploy and site Clean has to do with cleaning stuff up (duh) – basically deletes your target folder Site creates the project’s site – htmls, test reports, javadoc Deploy is the lifecycle we’re using most of the time (compilation, testing etc.)
• #13: Clean – has a single phase that cleans the target folder There are 8 phases in the deploy lifecycle, among them: compile - compiles java files and puts the classes file under target/classes (maven-compiler-plugin) tests - runs unit tests (surefire-plugin) package - creates a jar file, or any other configured package (maven-jar-plugin) install - installs the packages into the local repository (maven-install-plugin) Phases are additive so running mvn install will run all phases up to and including the install phase
• #14: A plugin is a collection of goals The maven-dependency-plugin contains several goals, amongst them tree, analyze and unpack Other plugin examples – maven-compiler-plugin, maven-jar-plugin This is how you run a plugin with Maven...
• #15: Convention over configuration here – most phases have by default plugins that are bound to them
• #16: I mentioned that plugins “bind” to a phase, here’s what it looks like during maven’s execution
• #19: POM stands for Project Object Model. The pom contains all info related to the project What to build When to do it Where should the artifacts be located It’s an XML file – back then XML was considered cool GAV - The unique identifier of the module. If a module is to be used by another one this is how you would reference it. Build info - what steps should run during the build, and at what order Dependencies needed in order to compile the project, test it and run it The data in the pom can be used by inheriting poms
• #20: Here’s a sample project It has one parent projects and two children that inherit from it
• #21: Father of all poms, contains defaults Used directories (sources, resources, target) Plugin versions Maven central repository link
• #22: Gav + packaging (Default packaging is JAR) Properties – key-value items Dependencies – my project’s needs Dependency management Build – plugins to run during the build
• #24: Dependencies are what the project needs in order to be compiled tested or run A dependency is added by adding its GAV to the dependencies section Dependencies can be scoped according to those needs. Compile is the default scope
• #25: Imaginary app… What happens if the two services depend on conflicting versions of guava?
• #27: Maven has a lot of plugins available for many many purposes
• #32: Why are superfluous dependencies bad for you? Because of what’s written above. This is very important for open-source writers and in general people who release libraries for other people’s usage. You can keep your room filthy, but keep your living room spotless You don’t want your lib to be the cause for dependency conflicts
• #33: dependency:tree – you can see what dependencies you have and where they came from. If you also want to see dependencies that maven did not take you should use –Dverbose
• #34: Maven’s way to resolve conflicts is to avoid them - the dependency closest to the built module wins, and if there are two dependencies the same distance the first one declared wins. If you’re lucky nothing has changes between the versions and everything will work. If you’re less lucky you’ll get a compilation error (That’s if WebServer is using a transitive dependency of Guava). If you’re less lucky - it will fail in tests with a NoClassDefFoundError Even less lucky - it will fail in runtime. Worst luck - implementation has changed and you’ll get bugs and not know why :( It’s even possible for something in ImageFetchingService/ImageResizeService to break when running in the context of WebServer because the actual guava version in the classpath is different than the one they were tested with. That’s why it’s best to use dependency management and have uniform versions.
• #37: Learning curve - Gradle is harder to learn. Probably any maven project you clone from github will be compiled by mvn clean install. Gradle is easier to add behavior to which means a person needs to learn your company’s comventions. Flexibility – adding behavior is very easy in gradle, you simply write a task inside the gradle file. For maven it’s either a new plugin or using ant or groovy plugins. Remember maven is opinionated Features Incremental building – Gradle’s is better. It recognized when the inputs/configuration of a task changed and executes that task Gradle files are code, you can just add logging inside gradle tasks – shows you the available tasks to run