I'm an author and a developer focused on build tools. I'm currently focusing on Gradle, but I have an interest in all build tools and most development infrastructure. I focus on Enterprise Java, Ruby, and the interface between Systems Administration and Software Development. The focus of my work is to make it easier for individuals to adopt open source software. Tim is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Wait… You Don't Have a Repository Manager?

  • submit to reddit

I’ve seen it all. I really have. The highly paid consultant from a well-known enterprise software vendor who once told me: “I don’t need to use an IDE, I do everything in Notepad.”… all the way to a client that was convinced the best relational database was the one they built in-house (my reaction: really? you can do better than MySQL or Oracle or Postgres? With one developer? I’d like to see this).

You and I work in an industry full of exceptional hubris, and, very often, exceptional ignorance. When I see the development team that doesn’t use an SCM because they are “too complex”, or a $200/hour consultant that whittles away his time in Notepad, it just reminds me that our industry is chock full of oddities. But, what are you going to do? As long as that SCM-less team gets the job done and that Notepad-using consultant delivers, it often makes sense to “let it be” – not everyone can be convinced to make rational decisions about development infrastructure.

Correcting a few Repository Management Myths

Trust me, I’ve tried to convince them all, but there’s something about dev infrastructure that encourages a new level of stubborn-headedness – a resistance to objective reasoning. Take, for example, repository managers. I can’t tell you how many times I’ve heard people appeal to the following myths about repository managers:

  • Myth: “We’re not big enough for a repository manager.” Reality: I’m a team of one for most of the projects I work on, and I rely on Nexus as place to store 3rd-party libraries, and as a way to isolate me from depending on a network. The size of your team has no bearing on the benefits of Nexus. Download it.
  • Myth: “The fact that you need a repository at all is a failure in how Maven is designed.” Reality: Every reasonable tool that manages dependencies downloads artifacts from Central – Maven, Ivy, Gradle. Are you telling me that you want to download all of your dependencies manually and check them into source control? (if so, I’m giving my notice today because that is insane….) Again, invalid excuse, go download Nexus.
  • Myth: “You only need a repository if you are publishing artifacts to it.” Reality: No, the benefits of Nexus as a proxy are huge. You can track your exposure to licensing and security threats, and it gives you a place to control what artifacts people consume.
  • Myth: “Our projects only have three dependencies, I don’t see the benefit.” Reality: Sure, your projects have three direct dependencies, but they likely have transitive dependencies. The problem with dependency management is that tools like Ivy, Gradle, and Maven have made it too easy, no one understands the underlying complexity. In this case, maybe this individual needs Maven training.

I’m drawing a line at repository managers.

If you develop Java-based or .NET-based software and you don’t use a repository manager you might as well just wear a shirt emblazoned with the words: “Doing it wrong and proud of it”. Here are some very basic reasons why you shouldn’t just accept the fact that your group doesn’t want to use a repository manager:

  • You’ll lose your license – Ok, that’s not true, but it should be. Remember, Central is a public resource, it is a service that is made available to benefit everyone, and it is also something that should be conserved. If you run a large development effort with tens, hundreds, or thousands of developers and you just don’t care enough to run a caching proxy, you aren’t being a good citizen of Buildlandia. (No one is going to revoke your Central license, but maybe this will get your attention.)
  • Because it is always better to be informed – While your colleagues may think you only use three artifacts from Central, I promise that if they were to take a closer look, they would notice that the build is pulling in more than that. Do they know about security issues for the components they use? Do they understand that OSS software is released under various licenses? Ignorance of legal obligations in OSS is not a valid defense, so if you suspect that the organization you are working for is flying blind on licensing issues, download a Nexus Professional trial and find out. It is always better to know.
  • Best-practice – In this industry it often pays to invoke this nebulous idea of “best-practice”. Ignore the fact that you’ve tried to make the case using solid reasoning and examples. Make an appeal based on authority. Tell your colleagues and managers that Nexus is used by some of the largest Media companies, the largest international banks, and the most critical government agencies. If you need to make this case, and you are running into problems, send an email to our sales team. We’re here to help you make the case.

Lastly, if you can’t convince your team to use a repository manager. Quit. Ok, just kidding, I’m not telling you to quit (although I can’t say it wouldn’t be a good reason). Maybe I am telling you to quit over this, maybe I’m not. You know what, I probably wouldn’t last very long on a dev team that willfully disregards repository managers.

Published at DZone with permission of Tim O'brien, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jammer Man replied on Thu, 2012/07/19 - 8:55am

Nexus: No.  Archiva: Yes.

Maven: Hell No.  Gradle: Hell Yes (or Ivy or Ant, but definitely not Maven).

... and I'm not just stating all of this because of my intense dislike of advertisements masquerading as articles. 


Java Guy replied on Thu, 2012/07/19 - 6:44am

Over 1k votes & at present 64% hate maven


Jonathan Fisher replied on Thu, 2012/07/19 - 3:11pm

Ivy should have been called [Maven]Envy. The best part about Ivy is it's reporting about how it decided to resolve your dependencies. I think it has the best chance to "do maven right." It needs wider adoption and more reporting plugins. But honestly, it's only a modest improvement and seems to be ran by a bunch of Ant fanbios.

Gradle is alright, but you have to learn another friggen language to use it. With XML you at least have a schema. With Gradle, you rely on interpretting a manual. That in itself is annoying as hell. I gues it's fast. That's good.

Maven was awesome, at one point, but too many bolt-on fixes have lead to a ridiculous specification xsd... and IT STILL doesn't separate project inheritance from the cross-cutting concern of build configuration. At least it has a ton of report plugins and wide adoption.

So ovreall? They all suck. Which leaves us: Maven is the best because it's what most people use and the alternatives are only slightly better, but not compelling enough to make a vast majority of people migrate. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.