Comments for A tale of two repository managers: Nexus and Artifactory compared and contrasted at http://wakaleo.com , comment 1 to 5 out of 5 comments http://wakaleo.com Thu, 09 Sep 2010 02:05:33 +0100 FeedCreator 1.7.3 http://wakaleo.com/blog/243-a-tale-of-two-repository-managers-nexus-and-artifactory-compared-and-contrasted#comment-80 [url=http://www.pdfqueen.com]Pdf ebooks searching[/url] service can also be used for the search of printing production, which might be bought in internet shops. - Mackenzie Sun, 14 Mar 2010 23:01:33 +0100 http://wakaleo.com/blog/243-a-tale-of-two-repository-managers-nexus-and-artifactory-compared-and-contrasted#comment-79 [url=http://www.pdfqueen.com]Pdf ebooks searching[/url] service can also be used for the search of printing production, which might be bought in internet shops. - Mackenzie Sun, 14 Mar 2010 23:01:32 +0100 http://wakaleo.com/blog/243-a-tale-of-two-repository-managers-nexus-and-artifactory-compared-and-contrasted#comment-53 Regarding the performance gained by eager fetching, we evaluated eager fetching of JARs in early Nexus versions but decided to rank it low on our priority list for a couple of reasons: 1) It only benefits the first user requesting a set of artifacts. Typically the bottleneck is the external bandwidth and thus if the first user needs to download 25mb of jars, the order of the requests would only marginally affect the overall download time. However, if you're copying from another system on a high speed LAN (as you would likely use for benchmarks to control variation in network congestion) then the network wouldn't be the bottleneck and things would in fact test out faster. 2) Maven makes requests for POMs during the resolution process that may ultimately be evicted from the graph. Fetching these jars is potentially wasteful and could result in build slowdown as valid requests have to contend with bandwidth from pre-fetched JARs which will not be used. Maybe that's not an issue if you process it as a background process, but if that's the case, I wonder how often the eager fetching is requesting JARs before Maven does. 3) Recent versions of Maven are able to make parallel requests for artifacts, and are pretty effective at saturating the available network when needed, I would imagine this would cause some interactions with pre-fetching. In short, I'm sure certain benchmarks in a completely clean system proxying from a LAN may run faster, but I would expect real world performance to be "typically negligible." Therefore in our view, the risk of complexity for the reward of small gains didn't pan out, but hey that's where choice for the user is better. I think it's just important to have perspective on the gains in real scenarios. Regarding the POM cleanup implementation, I also have pretty serious concerns about the implications of rewriting poms (not to mention the implied subtext of that blog title). I won't go into the details here but I would classify this also in the low upside, high downside category. Regarding the importing and exporting of the repository configuration, this seems like a moot point when you have a full REST API. In Nexus, everything is done over REST, so that means you can import and export all the configuration, not just the repository config via wget if you feel like it. In addition to the REST, Nexus supports the repository-metadata.xml standard used on Maven Central, where key information about a repository is available right inside the repo. This means that if so configured, anyone can discover the canonical urls for proxies, other known mirrors, what repos are contained by a group, and the release and snapshot type. This has been supported by Nexus since 1.3. Take a look here for a few examples of this metadata: * http://repo1.maven.org/maven2/.meta/repository-metadata.xml * https://repository.apache.org/content/groups/snapshots-group/.meta/repository-metadata.xml - Brian Fox Tue, 05 Jan 2010 18:17:47 +0100 http://wakaleo.com/blog/243-a-tale-of-two-repository-managers-nexus-and-artifactory-compared-and-contrasted#comment-52 Thanks for taking the time to provide all these details, Yoav, I appreciate the feedback. You're correct, I have not used the commercial edition of Artifactory, only read about it, so my understanding of the Artifactory Power Pack features is obviously less thoroughthan that of Nexus Pro. I'd be happy to try out the Power Pack to see how it compares in the field. - John Ferguson Smart Mon, 04 Jan 2010 13:32:23 +0100 http://wakaleo.com/blog/243-a-tale-of-two-repository-managers-nexus-and-artifactory-compared-and-contrasted#comment-51 As you mentioned, since your comparison is focused on the enterprise feature, I am surprised that while you did use a version of Nexus Pro, you didn't use Artifactory's enterprise features (Artifactory Power Pack - [url]http://www.jfrog.org/addons.php[/url]). We would have been happy to offer you a trial, as we give it away for free to open source users upon request. As a result, I think some of the points you raise are lacking information, so it worth clearing them up: [b]Searches and promotion[/b] – you mention this as one of the strong points of Nexus, but this is one point where we received completely opposite feedback from enterprise users that tried both. The searches in Artifactory, combined with searchable properties, are what are being promoted and overall artifacts management is a different aspect. Instead of dynamically creating repositories (identified by a cryptic IP address/timestamp combo), deployed artifacts themselves are identified during deployment. Then you can find them, manipulate them (e.g. remove sources), promote them to a different repository, or export them to disk as one unit. You can even promote results to multiple repositories by copying (which is a simple operation in Artifactory). The flexibility to combine and refine search results ([url]http://blogs.jfrog.org/2009/11/search-based-promotion-staging-and.html[/url]), together with permissions management and the ability to do something useful with the results is what makes the difference. In Nexus you can search, but once you find some results you cannot do much with them, except view them. Therefore, I can see how you would assume that searching provides some degree of promotion; however, I strongly suggest that you try it. While contrasting search capabilities, it is also important to mention that Artifactory's class/jar resource searches actually show you the classes found, unlike Nexus which only gives you a yes/no indication for jars containing your search. A user can also confine searches to specific repositories while searching. Artifactory can also search inside Ivy module files (e.g. check where an Ivy dependency is used) and has unique Ivy ([url]http://wiki.jfrog.org/confluence/display/RTF/Working+with+Ivy[/url]) and Gradle ([url]http://wiki.jfrog.org/confluence/display/RTF/Working+with+Gradle[/url]) support. [b]Speed[/b] – there were actually reports of opposite results, with more substantial benchmark differences - Artifactory faster by >40%!, see: [url]http://java.dzone.com/articles/maven-repository-manager-nexus[/url] (the 'performance' section). Artifactory offers eager fetching for jars (once a POM is requested) and a high degree of caching, which makes a big difference in speed. This may also be one reason for the memory consumption differences: and in an enterprise environment, which is the environment you are covering, it is typically negligible. [b]Security[/b] – Artifactory has offered LDAP authentication with tight UI integration in OSS since the beginning. Version 2.1.4 (to be released in a couple of weeks) includes LDAP group support with more flexible mapping options than what Nexus currently offers and high caching (thanks to Spring Security). Artifactory also has Kerberos and native NTLM integration (with HTTPd) as an add-on. [b]Site hosting[/b] – Artifactory is a full Web Start/Java FX repository (http://blogs.jfrog.org/2009/05/maven-and-javafx-story-of-twitterfx-pom.html) for hosting your apps in a secure way; offering central dynamic artifact signing and href rewriting. Again, this is part of the Artifactory Add-ons Power Pack, so I can understand how you missed this. [b]Maintenance[/b] – Artifactory has a very proactive default approach toward keeping repositories healthy. Repository reference cleanup is one example, and you can also block bad POMs (ones that are not parsed successfully by Maven, even if their checksum is correct—which is not uncommon). Another key feature of Artifactory concerns remote repository maintenance – you can import (or share via REST) the up-to-date definitions of the most common remote repositories, which makes the configuration error-free (spring, jboss, java.net, etcetera). The ability to nest reusable groups of repository definitions is also a very powerful feature in Artifactory that doesn't exist in Nexus and makes repository management much easier. One very important point that is missing in your comparison is Artifactory's integration with Hudson ([url]http://wiki.jfrog.org/confluence/display/RTF/Build+Integration[/url]), which gives you full traceability from your builds to Artifactory and back, including seeing all artifacts produced with their dependencies, and the build environment information. Thanks for writing this up, you are welcome to give a try to the Artifactory Add-ons Power Pack so that you can contrast it with the competing enterprise version. We at JFrog will be happy to assist you. - Yoav Landman Mon, 04 Jan 2010 11:18:37 +0100