We are currently using Artifactory with Gradle. I can’t say I’m impressed. The search capability is awful and the artifact results don’t have restful URLs.
Nexus has much better search and uses restful URLs. But nexus is a pure maven repository.
Will gradle work ok with Nexus both for publishing and consuming?
What are the pros and cons?
thanks
thanks
we have dozens of teams distributed across the world and 100K+ artifacts in our repo - so searching and sharing URLs to artifacts is a huge issue for us…
Phil,
Some of the restrictions of Nexus Baruch mentions are correct however:
In practice most enterprises have a mixed set up projects and build tools for their JVM based project using tools like Maven, Gradle, SBT, Gant/Grails build and Ant/Ivy. All of these tools source a large majority of components from the Central Repository aka Maven Central. It is using the Maven repository format and all these tools understand this format out of the box and interoperate with it nicely. It therefore provides little value to use a different repository format since you would be locking Maven and other tools out, whereas the Maven repository format provides a common format allowing you to interchange components between projects even if they use different build systems.
There is no specific Gradle plugin for Nexus since Gradle out of the box fully supports downloads from and deployments to Nexus and you can customize what you want deployed to Nexus with all the scripting power of Gradle to fulfill your own specific needs easily.
CI server plugins - while there is no specific Nexus plugin for a build pipeline yet Sonatype offers Jenkins/Hudson plugins as well as Eclipse plugins for Sonatype CLM that allow you to examine and validate security and license data of your dependencies.
Nexus very much has a configurable release and build pipeline. In fact all open source projects publishing to the Central Repository including Gradle itself and many, many others use it all the time. Nexus is the platform for the input funnel for the Central Repository via https://oss.sonatype.org/index.html and it is using the staging suite of Nexus with automatic rule validation, multi stage flows and notifications as well as Sonatype CLM integration. And that pipeline works with any build tools but we also offer the specific Nexus Staging Maven Plugin and Ant Tasks, which can easily be used in Gradle.
Besides addressing these points I would suggest to make sure the repo manager you choose provides you with the licenses necessary to scale easily and effectively across your dispersed teams and performs sufficiently with a number of servers interacting with each other (e.g. using the Smart Proxy feature of Nexus) and exposing the components to your configuration management tool of choice. Nexus has a REST API and it can easily be integrated with Chef or Puppet or any other tools and in fact many users do exactly that (http://blog.sonatype.com/people/2013/10/nexus_devops)
If you have any questions feel free to ask on the mailinglist, drop by on hipchat or attend a Nexus Live event (http://www.sonatype.org/nexus/participate)
@JBaruch, we are on Artifactory 3.0.2. I’m going to temper my criticisms of Artifactory’s search after using Nexus some more.
Both offer similar functionality. The main advantage I see of Nexus’s search is 1) restful URLs in search, so I can share searches with others 2) more results per page 3) the search UI is better in that I can type in any type of search in the global search field for anything (classes, artifacts by name, etc). Nexus is more like a Google search. For example, Artifactory makes me to to the class search to search classes.
Neither let me search manifests (best I can tell), which is important for our team.
A major issue I reported against Artifactory: https://www.jfrog.com/jira/browse/RTFACT-4610 There is no ability to search for package names. Sometimes a java artifact has package names that don’t correspond to the artifact GAVC, in this case there is no way to find the artifact. This has been a major issue for us. I don’t know if Nexus has this feature or not… I notice it is marked fixed now. But I tried it and didn’t get any results back. Perhaps I am using it incorrectly?
Without restful URLs, artifactory “breaks the web”. I expect page URLs to mean something, however state is either not sharable or hard to share (you have to through extra steps to share an artifact link, which still doesn’t share the full state of the current view). This is really important in a distributed environment with dev offices all over the world. We send URLs between the teams all the time via IM and email.
I personally can’t ever buy a product that doesn’t use restful URLs (my employer did though 
). I know why you don’t have them - someone decided long ago to use a lousy web framework (wicket?) and it’s probably tough to change. But it’s really annoying!
So my suggestions:
*allow many more search results per page (possibly infinite scrolling with sorting). *index on packages (you already index on Classes, so follow similar pattern) *index on manifest entries *global search functionality (think google home page) *restful URLs
please correct me if there are ways to perform any of the missing features I’ve listed.
thanks phil
Here are my comments on @Manfred’s reply:
There is no need to compromise on Maven layout just to meet some lowest common denominator. Using a proper binary repository (one that won’t lock you into Maven) allows layout transformations. This gives you the power to consume the artifacts in layouts you need (and not what Sonatype team decide for you), and get the same artifacts in different layouts from different repositories. E.g. you can get artifacts in Maven layout for your Maven builds and get the same artifacts in Gradle (or any other layout) for all the other, less rigid, build tools. Same applies for Maven Central. The fact, that this repo is trying to lock you into Maven layout shouldn’t stop you once you use a repo with on-the-fly conversions.
Artifactory, naturally, also supports plain resolution and deployment, and you don’t have to use our plugin. If you select to do so, you’ll gain additional advantages, like attaching dynamic properties to your artifact and harvesting and deploying detailed build information. Those aren’t available when using plain resolution and deployment, thus they aren’t available with Nexus.
The Hudson plugin for CLM integration with license and security information is nice. Open-source plugins for all the major CI servers that provide full build information and allow out-of-the-box promotion pipeline creation are nicer
Ah, and thanks to Manfred for bringing up the licensing issue! I totally agree, it’s very important to choose a repository that allows you to grow without paying more each time your team gets new developers. I suggest going with the one that has per-server license, not per-seat.
Great comment regarding dispersed teams, too. When using local repositories in different locations, it’s important to select a product that has better replication features. For example, it should be smart in terms of network utilization. If one has a file under a certain name in one server, and exactly same file under a different name in another server, wouldn’t it be dreamy, if no network traffic occur? Since a user might have different network topologies, both push and pull replication should be available. Event-based replication is also very important.
Needless to say, that even the fullest REST API (such as Artifactory’s) can’t be enough when talking about full automation. Most advanced and demanding users want to implement their own logic inside the binary repository (usually in a form of a plugin). I can only advice to choose one that has descent DSL in a proper scripting language and simplest deployment procedure for your plugins.
@phil.swenson thank you for your feedback. It’s rare to get such a reasoned and detailed one.
Regarding the global search - The tradeoff here is between the amount of reach results vs. the work you need to do to specify what exactly you are looking for. I am sure you won’t be pleased if we spill out for you anything we can find about search “log” - all the files, all the entries inside the files, all the files with properties that contain “log” in name or value, etc. In all the binary file searches I know of, the default search searches by file-names (simple search in Artifactory, top right corner). When you want to search for something inside the file (e.g. entry in zip or class in jar), or search files by their metadata, you have to do some additional clicking (go to gavc or properties search in Artifactory).
Regarding the UI - both number of results and bookmarkable urls for search results - your remarks are valid, although there is a simple workround I can suggest: you can run the searches in their REST API forms. No pagination there. They are also bookmark-]able, since they are, well, REST.
It will work fine with Nexus, although I do prefer Artifactory.
Hi Phil,
Regarding your troubles with Artifactory search: -------------------------------------------------------------------- I’d speculate you are on an old version of Artifactory. We aren’t aware of any significant search issues. Can you please elaborate in Artifactory user list so we could help?
Regarding the pros and cons themselves: ------------------------------------------------------------ As you mentioned, Nexus is a Maven repository. Which means, it will work with Gradle as long as Gradle behaves like Maven.
Artifactory, on the other hand, fully supports any layout, including Gradle native layout and any custom layout that works for your organization.
Next, Nexus doesn’t have any special Gradle integration. On the other side, JFrog developed a Gradle Arifactory Plugin that introduces a new DSL for resolving and publishing artifacts from and to Artifactory. It includes features like attaching deployment-time properties, generation of detailed build information etc.
Another issue is integration with CI servers. Again, Nexus doesn’t have any. JFrog has a set of open-source plugins for Jenkins/Hudson, TeamCity and Bamboo, that specifically target Gradle builds and give you full control of your build->binary repository integration in your CI server. That includes control of resolution and deployment repositories, resolving/deploying users, attaching deployment-time properties, generation of detailed build information and much more.
Release pipeline. Again, with Nexus you’re on your own now. Maven has the release plugin, but it won’t help with Gradle. Using Gradle with Artifactory in CI server gives you out-of-the-box release pipeline. Artifacts can be automatically converted from snapshots to releases, staged and released in a click of a button or by using REST API. Full customization of the release process is supported by coding your own logic in the user plugins.