Why Gems is mere carbon and Maven is a schmuck

The first time you run Ruby gems to install components, you have to admit it all looks pretty slick. The application is set up and the developer goes to work, adds a gem here and there

Then the downside becomes painfully obvious.

All the components that were installed by the developer have to be installed by each and every other developer who wants to work on the application.

All the components have to be installed on all the servers where the application is to be deployed.

Truly, I am not kidding.

So for every component added to the application you will have to run this gauntlet. Since component changes are in flux and need to be dealt with as such, instability is bound to result.

To add insult to injury, the concept out-of-the-box further imperils Ruby's Cloud-ability, because it requires root access to deploy gems. As long as this issue is not addressed, Ruby is bound to miss out on the movement.

The Ruby community soon enough saw the downsides of the gems approach, but as solutions go, the proposed practice is lamentable. Gems need to be unpacked (similar to extracting content from a ZIP file) and added to a subfolder in the product. Then the application will have to be customized so that it reads the gems' content as part of the project structure.

I am sure the Ruby community would have much preferred a cleaner solution like Java offers. Instead they chose the enticing route of setting up their own disruptive technology. Too bad the disruption was for the user, not for competing technologies.

The Java community will not be left off the hook, however, having introduced and hailed its own piece of well-intended, but flawed reasoning and I will gladly go against the grain to make my case.

Maven has the concept of a repository where dependencies can be stored (usually JAR files). Some reasons are given on the Maven website why those dependencies must not be stored as part of the project; takes too much room, impedes checkouts and does not require to be versioned.

Can you believe that those are actually the real reasons for Maven's repositories? You better believe it, because there is not much other value to the concept, even downsides.

For one, there is the downside of having a compile-time dependency on external sites for which I wager most organizations have no Service Level Agreement in place. Unacceptable to any serious company. Though there are ways to bypass the problem by setting up a local repository, most of the time that is overkill, introducing more complexity than the value you get out of the deal.

And let's not forget the extra hassle you get when setting up your development project. Normally I select the JARs in the library subfolder of a project and be done with. Not so with a Maven repository. You will actually have to go through the POM and harvest the dependencies one by one.

So here is Maven with its fancy repository, saving you disk storage and checkout time. Would you consider that a good trade-off for an extra layer of complexity and more hassle?

If you build your application, always internalize your dependencies whenever you can. You keep your teammates, your systems operator and yourself much happier this way.