Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 231 posts at DZone. You can read more from them at their website. View Full User Profile

Maven repositories in anger!

  • submit to reddit

Every build systems worth his salt acknowledges Maven dependencies repository. Even those vehemently opposed to the way Maven does things, like Gradle, still uses repo1.

Wait, repo1? If there was only repo1. But nowadays, every project publishes its artifacts in its own repository. For some providers, like SpringSource and JBoss, I think it may be for marketing reasons. But whatever the reasons are, it only makes the job of the enterprise repository manager harder, since he has to reference all those repositories.

I also stumbled upon another serious glitch in repositories this week. My client bought JBoss Enterprise Application Platform (JBoss EAP) 5.0. Now, suppose we want to compile our code against JBoss EAP’s libraries using Maven. Guess what? Those libraries are available in no accessible repository: check this issue if you don’t believe me. Now, support proposes two solutions:

  • Either manually put EAP’s libraries in our own repository, reconstructing each POM
  • Or use Maven’s system path to point to a local (or network) JBoss EAP

Is this really the level of support we are expecting from a major player like Red Hat? Unfortunately, this is only a single real-world example of things going awry regarding Maven repositories. I’m afraid there are more going around beyond my meager knowledge, and even more to come.

Repo1 was meant to ease our life. I really wish we could go back to this simple scheme once again: stop tackling problems brought by providers and provide answers to problems brought by the business.



Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

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


John J. Franey replied on Mon, 2011/06/20 - 6:28am


I'm not sure the root cause of JBPAPP-135. Are the EAP jboss AS binaries different than the community binaries? Are not all jboss AS community binaries released as LGPL? Are they not all on jboss maven repostiory? JBPAPP-135 does not specify the inaccessible artifacts by groupId, artifactId and version, so I don't know.

Jboss proxies all major repositories. Using only the jboss maven repository is sufficient for many projects. Ask your favored public maven repository to follow that example. See:

Finally, to anyone thinking they must create their own maven repository in order to distribute their open source project.... please don't. Its easy enough to upload your release to Central:

If all jboss eap binaries are identical to community released versions, then pointing to the jboss maven repository will be sufficient because it proxies Central and contains all community released artifacts.

Nicolas Frankel replied on Mon, 2011/06/20 - 7:17am in response to: John J. Franey

John, I'm sorry if I mislead you into thinking that open source projects must create their own repos. My point is exactly the contrary: use repo1!

As for your question, yes, the binaries from EAP are not the same from the community edition: they are signed and Red Hat cannot guarantee they are compatible with their open source equivalent!

John J. Franey replied on Mon, 2011/06/20 - 9:31am in response to: Nicolas Frankel


No problem. I didn't think you misled me. I was trying to confirm/affirm your point, and point out, even though there may be exceptions (like signed jboss EAP binaries), there ARE public repositories that proxy others. I don't want to contradict in spirit, because I agree with you...but repo1 is a mirror of central (, so 'use central or a mirror!' might be a more accurate mantra.

As far as this issue with signed jboss EAP binaries, I'd like to understand it better. Do you have a link to the Red Hat position?

I'm not sure about the level of exposure we have to this risk of an incompatibility between community and EAP binaries. Important to me is build time compatibility, not runtime. I have no intention to deploy jboss binaries in my application and I think you would agree. I would instead use scope 'provided' not 'compile' or 'runtime' for jboss binaries included in the EAP right? I'm safe if I stick with build time dependencies on jee standard api which jboss includes. I'd be in trouble then only if my project had a build time dependency on an EAP binary that was build time incompatible with the community version....right? When is it reasonable to build an app on these?

Nicolas Frankel replied on Tue, 2011/06/21 - 2:06am


Concerning the link, you can check the Red Hat knowledge base, provided you have a Red Hat account with paid support associated.

Second, I completely agree with the provided scope. The problem lies in that as of now, Red Hat doesn't guarantee the binary compatibility of an Open Source library versus a signed one. That means my code may compile just fine with the OS one, and then explode during runtime due to such a incompatibility!

John J. Franey replied on Tue, 2011/06/21 - 7:49am in response to: Nicolas Frankel


The root cause is two different artifacts with the same groupId, artifactId and version. Woe be to us. Without a way to distinguish between these binaries, it will be very difficult to keep repositories pure. EAP subscribers need to protect their repositories to remain purely EAP. Non-EAP subscribers need to protect their repositories to remain purely Non-EAP. However, I think the Non-EAP subscribers will have an easier time of it, assuming that an EAP public repository, if there would ever be one, would be secured for access by EAP subscribers only, and that EAP binaries would never, ever get mirrored through central. Seems to me EAP subscribers are at greater risk than non-subscribers of a unstable solution; how ironic.

Until this is cleared up, we really don't want EAP binaries to be made public through central or a mirror like repo1.

matt inger replied on Tue, 2011/06/21 - 9:49am

Why not use Nexus or Artifactory? You can use either of these to:
  • Host local repositories
  • Proxy to public repositories
  • create groups which contain multiple repositories of the above
  • specify routing rules to explicitly resolve ambiguity
If there's an artifact that's not in a public repository, download it, and upload it into nexus or artifactory. On top of this, you get a nice side benefit. Since everything eventually gets cached in your repository manager, you don't have to actually go off network to do your maven build.

Sirikant Noori replied on Sun, 2012/01/15 - 1:16pm

Which is why setting up a local caching repository using Artefactory is increasingly useful. Use it as a cache to some obscure vendor-specific repo, and upload hard-to-find or not-published artefacts there.

If only there was a way to peer them.

Comment viewing options

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