Maven: Why bother, and How

Use of Maven (or similar) is orthogonal to your argument. If you need your dependencies on your own infrastructure then you host your own maven repository?! Surely still an improvement over putting them in a source code repo.

Oh, and if you’re using something like Sonatype, someone is probably paying quite a lot for things! :wink:

Exactly @ nsigma.

One could even have every developer run a local repository (or a flat file repository) and one can still benefit from other things maven gives you - transitive dependencies ware already mentioned. Dependency management without descriptors and a tool that lets you do excludes and forced failure on version conflict is…yea…i dunno. Impossible, senseless, insane? In addition to the problems one gets with binaries in git repositories, as cylab already stated.

Another reason why Git is a bit shit compared to Subversion btw…

Cas :slight_smile:

Sometimes I get the impression that hijacking threads with even more rants about totally unrelated topics is exactly your thing prince.

Git has other advantages over subversion that are more relevant for the vast majority of source code projects, where the only binary artifacts one cares about is dependencies. And if you store your binaries in your source code repository, you’re doing it wrong, simply put (*). Dependency management is often about updating minor versions, having updates on patch versions of transitive dependencies, splitting things up code in modules. If you put every version of every dependency in your source code repository than… no… i don’t know what to say if it’s not clear by now.

Back to topic: Maven enables dependency management. Independently where and how your repositories are located. Dependency management is an undeniable requirement for nearly every software developing company out there for sure.

(*) Really no one on earth is interested in 0.0001% of developers that might have a few good reasons to be the special snowflake here.

I really hate bloated and complicated configuration tools. If you possibly can just stick to makefile’s and the like.

Configuration hell is a thing and the favourite weapon of office warriors for political gerrymandering and filibustering. This can be especially bad in Enterprise projects where 80% of the time is spent doing nothing.

Love this quote: "If you don’t actively fight for simplicity in software, complexity will win.

…and it will suck."

Also @princec concerning git: lies!

Games development is not a special snowflake case (especially on this board!) and it’s also the case that generally requires binary files that are several orders of magnitude larger than the source code. Git is a terrible choice for games development (which is why nobody in the industry uses it).

Cas :slight_smile:

ps. I like rambling threads

There are options for storing large binary files in (well, kind of with) Git.

That’s kinda orthogonal (I’m liking that word today :wink: ) to the shit idea of putting dependencies in source control. :persecutioncomplex:

Well, that’s lucky! ;D

PS. all PraxisLIVE dependencies are currently in source control!

If you think of it instead as “project repository” rather than just “source” it makes a lot more sense. It’s worked very, very well for us for the last 20-odd years making Java games, and latterly a Unity one.

Bringing this thread screechingly back on subject, we developed an Ant script or three that reliably builds all of our games on all of our target OSes for all of our target platforms. We even have JVM binaries in SVN, as well as NSIS binaries for Windows builds, etc. When confronted with a brand new development machine we only need to install the JDK and Eclipse and the Subversive plugin, check out the repo, and whack Ant and out comes everything ready to upload to Steam etc etc. without actually having to remember to do anything else. I really don’t like the Ant build script, because it’s a really daft way of saying “do this, then this, then this” and I’m not really sure why anyone would ever design such a system to work that way when they wanted to do a build. It reminds me of that old joke about the toaster, the king, a software engineer and a hardware engineer.

Scar really does seem to be a great solution to what should be a really, really trivial problem. It’s not even complicated to have made - any one of us could have written Scar in its entirety in an afternoon - but there it is, already made. I think it’s definitely worthy of investigation.

Cas :slight_smile:

Wouldn’t it then be best to also check a JDK and Eclipse into Subversion to have a really reproducible development environment? I mean, how do you ensure that new developers get productive when oracle or are down? :stuck_out_tongue:

In case it wasn’t brought up. A benefit of using gradle is that it is importable by any (decent) IDE out there.

Also gradle has the concept of a gradle wrapper script with a .gradle folder in your project, so you can self contain the whole buildsystem in your “project repository”. You can also specify file dependencies or set up a flat files repository to look for your dependencies in a local (in-project) folder.

Another option would be to modify the gradle home directory using the -g option (e.g. in the gradlew script) to have the gradle cache inside your “project repository” as well, so you could have online bound dependencies that also work offline from a fresh checkout.

So if you want to have it the static way, you can have it with gradle, too - with the added benefit of being able to import the project to any IDE and being able to script some parts of the build in a “real” programming language…

I think this article sums up some intresting points regarding this topic in case anyone is interested:

In case anyone really wants to do this (regardless of seriousness of the quote) please make sure that you are using OpenJDK and not Oracle JDK because redistributing a modified Oracle JDK is violating their licence.

Take a look at section C which states:

“Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs…”

Take a look at the following link what you need to consider when redistributing Oracle JDK (example Java8):

PS: sorry for posting offtopic but I felt like shedding some light on this might be useful for anyone who did not know yet.

Thank you for being offtopic, the article you linked is very interesting!

Luckily soon to be a thing of the past! :slight_smile: And even so, it depends what you mean by modified too - there’s stuff you can modify (remove) within the terms of the license. And there was the old SE 8 compact profiles.

Like many things in programming, this comes down to context and preference. What makes sense for one person or team might not make sense for another person or team, or the same person or team at a different time.

It’s not as simple as saying “Maven is always good” or “Maven is always bad”. Maven is a tool with its own pros and cons, just like any other tool.

I’ve been in codebases where Maven was overkill. I’ve also been in codebases that used the “just use this folder of jars” approach to dependency management. The directory of jars might work for small projects, but if you have dozens of people working on it over 10+ years, eventually this becomes unwieldy.

“Okay time to deploy… wait why do we have two versions of this library in here? Which jar do I actually need? Oh great, that jar actually contains other libraries…”

Back to OP: like I said, if your setup works for you, then that’s cool. Nobody is going to force you to use Maven. But if you want to understand how it works, I suggest using it with the next hello world program you put together. You might find out that you like that workflow better.

Thanks Kevin!

For my own projects, at this stage, Eclipse is quite enough.

I suspect that letting AudioCue get mavenified on the GitHub site was not a good move. It is a small library. If someone wants to use it with Maven, I’m sure it would be quite easy for them to make the needed changes. Better that than for someone who is making smaller scale applications to wonder wtf do we need to have the code buried under 6 or 7 file folders. If I recall, TinySound hasn’t been given the Maven treatment and it is still in use. I am debating whether to roll that back.

Reading all the digressions and conversation has been interesting. Am happy to have stimulated a good discussion even if a fair bit is over my head and slightly off-topic.

I’d like to put in that we keep in mind that there are Java coders at all sorts of levels and with all sorts of goals here. You don’t have to be a super capable programmer to design and code a terrifically popular game or application (or maybe well-loved by a few but still worthwhile). There are other factors, many being quite mysterious. The code is a means to realize an idea, and Java remains quite sufficient, it seems to me.

Except there’s a somewhat different question in there. Using and publishing to Maven Central is a useful way to distribute a library. And it doesn’t stop people just grabbing the JAR or source. Of course, learning and configuring the publishing process is “fun”. But that’s also where the benefit of Mavenizing a library is.

Mind you, it actually appears to have been Gradle-ified! :slight_smile:

Goes to show how removed I am from both, to get them mixed up like that.

To provide a small amount of my own thoughts: for a long time, I just used the built in build system of IntelliJ IDEA. However, I wanted to add the kotlinx-coroutines library, and there was no easy way to download the jar file and put it in as a library. They suggested gradle, and so after a lot of playing around, I migrated everything. It has come in handy a few times–say I want to show off the latest build of my game, but I’m on a different computer. I just download the git repo and run ./gradlew build, and bam, it’s up and running.

It’s not the worst thing to avoid build systems, but they have a bunch of benefits and few downsides. The only thing I didn’t like was moving everything to src/main/kotlin.

The thing I mostly hate is XML, closely followed by half-assed DSLs.

Cas :slight_smile:

You don’t have to do that. You can just specify the location of your sources via sourceSets.main.kotlin.srcDirs = [“some-path“]