Maven: Why bother, and How

General Discussions
#1

I have been doing okay with Eclipse, until the new modular Java arrived, for my projects. I’m assuming in 6 months or so (if they haven’t already done so) the folks at Eclipse will catch up and things will be fine again.

I don’t understand what the deal is with Maven. What does it provide that Eclipse doesn’t? (Please include some “simple, easy to understand” language before going into technical depth.)

I posted a project on GitHub and a helpful Maven enthusiast added a bunch of file folders making the simple project have twice as many layers. I’d prefer not to let go of my backwards URL + projectname package structure as a way to reduce what seems to be needless folders. I let the change stand. But I don’t understand the tradeoffs, and I am reluctant to devote however much time to learning yet another tool just to find out if I really need it or not.

Is Maven something that one uses along with Eclipse?

If someone convinces me Maven is better or worth switching to, are there some guidelines or suggestions about how to convert from one environment to another?

Call me clueless. That’s okay. It’s true about somethings, and not about others where I have put in considerable effort and have shared what I learned. (Continues to be in grumpy mood.)

Thanks in advance.
8)

#2

What does Eclipse provide? I’m assuming it doesn’t have its own bespoke build system?! I’m assuming Ant by default?

#3

Nah, I am assuming @philfrei just clicks on Export > as Runnable Jar (+ extract build path dependencies into JAR), which is fine for all non-collaborative/non-continuous-built/non-continuous-integrated/non-continuous-deployed projects that also no one depends on as a library.

But as soon as you must omit the “non-” from any of the words above, a dedicated command-line-executable build system (which is not your IDE) becomes a necessity. In short: You do not want people to install Eclipse just to build your project. I always HATE it when I see GitHub projects checking in their .classpath/.project files with possibly absolute file path references to the Jar files in a C:\Users\SomeUser\Downloads\some.jar file.

But in short: When you ask why you need Maven and you need people to tell you the advantages, then you don’t need it and you will run fine with Eclipse alone.

#4

Seriously, wtf?! :o So, that’s what those bloody files are about. Never used Eclipse. In NetBeans, the default build system is Ant.

Just because these things are CLI executable @philfrei doesn’t mean you have to use the CLI - all main IDEs have UI support for Ant, Maven, Gradle, etc.

I would recommend using one - make your projects IDE agnostic - you never know when you or someone else will want to build your code in something else.

Maven is useful (and annoying!) for handling download of dependencies for you, amongst other things.

#5

Eclipse has its own incremental Java Compiler (ecj). That’s why you also do not need a JDK (only a JRE) when building Java applications with Eclipse. The “nice” thing is that ecj and javac behave very differently in a lot of very subtle ways: E.g. how to resolve the receiver class of an inherited static method call. Has caused some trouble in the past for me.

#6

Yes, I know it has its own compiler. Had a few PRs for code that wouldn’t compile in the past due to “inconsistencies”! :smiley: So I guess I shouldn’t be surprised that it has its own bespoke build system - never really thought about it.

Incidentally, ecj isn’t the only incremental compilation option.

#7

Thank you for this question @philfrei. I kept getting a warning with JInput and asked my co-worker who knows what he’s talking about, how to fix it. He said “just use Maven”. I tried and successfully failed, mainly because I had no idea what Maven was or how to use it.

#8

Thank you for this.

What I do for compiling: Export -> JAR File, and then in the steps that follow, click additional sources (from other projects) for inclusion on an as-needed basis.

Also, the “Configure Build Path” function (via right-clicking on the project) allows one to specify any external jars or libraries or Eclipse projects that are needed for compiling the project.

I do not use Export -> Runnable JAR File. Maybe I should, but when I was first trying to figure out how to compile with Eclipse, I was unable to get that to work. I’ve put it out of my mind as an option given that the JAR File option works perfectly well.

Well, maybe not so perfectly at the moment. To create a jlink build, I am currently going through the steps I put in my “manual walkthrough” that was just posted a few days ago. I look forward to automating that process (now that I understand it better) with ANT but maybe I should be thinking about doing so with Maven instead? Either system is going to require a learning curve.

@KaiHH, Are you available for some more follow-up questions?

I thought Github was built to be a version control tool, built for collaborative projects. Individuals can each be connected to a collaborative project via a “fork” and develop using Eclipse locally. How does that reconcile with your statement about non-collaborative projects only? I assume I am missing something.

If I use Maven, will I be giving up all the editing support Eclipse provides? I like my colored underlines and highlights and refactoring options and other goodies. Or is Maven something that one sets up to read from the source code structure that Eclipse also manages?

I have more questions, but will hold them for the moment.

#9

A lot of these questions will clear up when you read this:

Just take an hour or two, read these two and possibly google more for “Maven tutorials” or “Maven howto” or “Maven getting started”.

#10

I use Maven, Gradle and Ant in Eclipse.

When I use Maven in a project, I can develop in Eclipse, another contributor can develop in Netbeans, another one can develop in a simple text editor and build in command line, another one can use IntelliJ IDEA. Maven is able to generate IDE-specific files if needed, using a “good” build system allows me not to force developers to choose my favourite IDE and it has the numerous advantages KaiHH already mentioned. Each build tool or build system has its pros and its cons, I advise you to learn to use several of them. For example, Ant is very flexible but it forces you to write a lot of code to do everything, Maven is more concise but more strict, Gradle is somewhere between Ant and Maven.

#11

When you have a collaborative project, you usually want to also have some form of quality gate/control. This at the very least allows you to automatically check whether the project compiles successfully and usually should also include some form of tests (unit test, integration tests, …), that are being run as part of a build, and for more sophistication also static code analysis tools (SonarQube, CheckStyle, FindBugs, …) that check certain pre-defined quality metrics of your software.
In order to give quick feedback to contributors about what they are going to check in when they do a Pull Request, you want a continuous build system that performs those checks against the code automatically. One very popular continuous build system used in the open source world is Travis. But Travis is not a person clicking buttons on a graphical user interface in Eclipse. Travis needs to execute command line tools to do the job you want it to do. And one possibility to do all this mentioned above is Maven. Other possibilities, like @gouessej mentioned, is Ant or Gradle; or quite simple even Makefiles or plain shell scripts.
In those situations you simply need a command-line tool which automates most of the dependency-download, build, test, package, deploy (possibly to a public Maven repository so that other projects can use your build artifact immediately) pipeline of your project.
Source control and collaboration platforms like GitHub provide you with great support for all of this. GitHub will even show you whether a Pull Request of someone else passes all those quality gates before you can even merge it.

Eclipse provides you with a lot of the tasks as well:

  • Configuring your compiletime and runtime build path (dependencies of your project in the form of Eclipse-only projects in your workspace and jar files)
  • Assembling a jar file from your project’s compiled class files and resource files
  • Running JUnit/TestNG tests
  • and there are plugins which provide more functionality (such as deploying a .war file to an application server)

The point is: The functionality an IDE provides you with requires a graphical user interface and requires a user clicking on buttons. This is NOT automation. And you want automation for all of this in a collaborative environment.
I myself consider it a great confidence boost when I see that little “this project builds just fine badge” on a project’s readme file, because then I know: This project actually compiles fine and I can be quite confident that when I clone the project and let Maven build it and create an IDE configuration (mentioned by @gouessej ; think Eclipse’s .classpath/.project files) that this will work without any problems out of the box and without me having to manually download missing jar files from somewhere and tediously configuring the wrongly configured build path.

I also recommend reading this: https://en.wikipedia.org/wiki/Continuous_integration

#12

My 2 cents on the topic:

  1. read https://maven.apache.org/guides/getting-started/ really helps
  2. selling points:
  • convention over configuration: if you use maven, you agree to use a set of conventions (for example source code in src/main/java) that speed up setup, build, test, etc… If I want to build your source code for example and get the jar, I have only to run “mvn package” and I have the jar
  • transitive dependency: you declare in your pom.xml (basic maven file) what dependency you need and maven download all required libraries from open, free repositories (see https://mvnrepository.com/ ). Speed up update a library and dependencies, etc…
  • plugins: this is where maven rocks (IMHO). You have a lot of plugins that can be configured to attach to a particular phace (before build, after build, before test, etc… ) a do a lot of things. Like for example build a site from your repository, run test and save results, run static analysis of your code etc…
  • IDE neutral: does not require anyone to use a particular IDE: Eclipse, Netbeans, shell ? Maven doesn’t care
  1. about Eclipse. Maven is “Apache Maven is a software project management and comprehension tool” and Eclipse is an “Integrated development environment”. Both of them force you to work on a project in a particular way, Maven is more strict on project, file and directories organization, so other people can work on project more easily, applying patterns
#13

Personal biggest advantage Maven provides for me are:

  • all neccessary dependencies are summed up in the pom and are downloaded automatically and if you checkout your project (no need to browse for any .jar files)
  • it supports the build process a lot better than eclipse IDE
  • You have some nice additional plugins provided by maven
  • (not relevant for me right now but working collaborative Gradle or Maven is a must imo)
#14

Of those two, Maven every time! Have a read of http://wiki.apidesign.org/wiki/Gradle (and the linked to https://timboudreau.com/blog/maven/read). Agree wholeheartedly that a declarative build system, and one in which you (or your IDE) don’t have to run the build to figure out what the build does, is massively better than an imperative build system.

#15

Gradle wins for me over Maven because I hate XML format. Gradle uses Groovy or Kotlin, so I can use real code to build real code.

#16

Haha. So I guess those blog posts are falling on deaf ears then! ;D

#17

This emphasis on declarative systems imho just makes them inflexible and impractical. In the end you need to do a lot of dirty and ugly tricks to do anything nonstandard or put in a lot of effort to do it cleanly. Therefor I take a proper programming language over a declarative system any day.

Maven is good to define a project and it’s dependencies, but it’s not a good build tool. I like gradle better.

I also can only partly agree with the argument, that in maven/declarative systems it’s easier to determine what a build does without running it. You still need an understanding of the used plugins.

Also reading code and figuring out what it does should not be too hard for a developer. Wading through plugin documentations (if existant) to find out what a configuration does is not always simpler. At least for humans (but the eclipse and idea gradle plugins also work reasonable well)

#18

Used Ant for 15 years here to do all of Puppygames’ stuff.
Ant is quite shit.
Maven looks similarly shit, so I’ve not bothered with it. Gradle pops up now and again and appears to be like Maven but they’ve changed the syntax of the shit a bit, but fundamentally, still seems to be a nuclear powered Leatherman to do the job of a knife and fork.

If only someone would make a simple Java API to do buildy things and then we could just use jshell.

Cas :slight_smile:

#19

Nate’s SCAR library does just that- a java API to build Java projects.


But since it’s not a standard, very few people are familiar with it so I suppose it doesn’t help reduce the fixed cost of learning a new tool in addition to Ant, Maven or Gradle.
Since libgdx uses Gradle, that’s probably the best thing to recommend to java game devs

#20

Gradle is meant to be a declarative build system though! It’s just that if you let people write “real code” … Maybe most people are more disciplined and follow Gradle’s guidelines more carefully, but the few times I’ve had to work with projects using it I’ve found it a bit messy.

Now, like @princec most of what I’m working on still uses Ant. Writing imperative code in a language meant for declarative use. Now that really is a warped idea! :smiley: