JFrog Artifactory 4 Overview

What’s new in Artifactory 4?

  • Complete UI facelift: A fresh and modern look and feel, providing a rich user experience with configuration wizards, convenient “Set Me Up” code snippets for simple copy/paste integration, easy permission management, smart data tables and more.
  • Single package type repositories: Context-focused repositories for better performance when calculating metadata, and for more organized and intuitive workflow.
  • Groovy 2.4 for user plugins: letting you enjoy the latest Groovy language features.
  • Smart remote repositories: Define a repository in a remote Artifactory instance as your remote repository and enjoy advanced features such as automatic detection, synchronized properties and delete indications.
  • Docker enhancements: Aggregate all of your Docker repositories under a single Virtual Docker Repository. View detailed information for each layer of your Docker images.

 

Here are some additional questions and answers that are relevant to the broader audience.

 

Question: Is there any way to help users generate NPMRC files similar to how it’s done for Maven settings.xml?

Answer: The Set Me Up feature provides snippets for all the supported technologies including NPM; not only for Maven. Just select an NPM repository and click Set Me Up.

 

Question: If I bundle repositories of different packaging types (including Smart Remote Ones) under a virtual repository, am I able to deploy to this virtual repository and have it choose the correct bundled repository depending on the packaging method I use? This should be working when I’m forced to use single packaging types.

Answer: Currently, you can’t deploy to a virtual repository. Moreover, in Artifactory 4, repositories are single type by design, so you can’t mix repositories of different packaging formats under the same virtual repository. Having said that, we are currently looking into how deployment into virtual repositories should work.

 

Question: In the Home page, many features and package types are displayed as “Available”. What does that mean? Does it mean we can use it without an additional license, and we do not need to install additional packages?

Answer: “Available” means that you can use it; it’s available for you to use. Some addons such as S3, High Availability and Multi-push replication require an Enterprise license, so they will not be available for you if your current license is Pro. Sorry for the confusion, we aren’t done with the Home page yet :)

 

Question: What is the cost of remote listing? Why wouldn’t I always do it?

Answer: When the other side is Artifactory – there is no cost. That’s why we enable it when Smart Remote Proxy is detected. For others – we don’t know. That’s why you have the option to disable it.

 

Question: Caching scenario: what if artifacts get deleted within the remote repository – are they deleted in the source repository, too?

Answer: No, and that’s the difference between the caching scenario and replication with deletions enabled. What’s more, we’ll even warn you if a remote artifact has been deleted so that you can save your cached copy; it may be the only copy left that is available to you.

 

Question: When you configure a repository as a Docker registry, why do you need to specify v1 or v2? Why not make them all v2 and let the Docker client figure out which it is by polling for /v1 & /v2?

Answer: V1 only works with Local Repositories. If you want to use Remote and Virtual repositories you need Docker V2. For Local Repositories, we need to know which index Artifactory should generate and which APIs to expose – V1 or V2? The client can fall back, but not the server. The servers should implement only one of the protocols.

 

Question: Can the home page show artifacts from local repos vs. remote repos separately in version 4.x?

Answer: The Home page only displays the total number of artifacts. For details about the number of artifacts in each and every repository, please refer to Monitoring Storage in the Artifactory User Guide.

 

Question: Will all docker images be cached in the remote repo?

Answer: I am not sure what you mean by “all”, but any image that you download from a remote resource, or a virtual repository that resolves to a remote resource, will be cached in the remote repository cache.

 

Question: When you point to multiple Docker repo’s do you need to specify separate ports for each of them or will NGINX handle the ports per Docker repo?

Answer: You need to add a rewrite rule for every Docker repository that you use, assigning a unique port (or virtual host) for each one so they can be resolved in host:port/imageName format.

 

Question: Is Artifactory well suited for C/C++ artifacts targeting Win, Linux and OS X platforms? E.g. .lib, .exe, .a, .so, .dll

Answer: Of course. Artifactory is well-suited for any binary file (i.e. not text), and .lib, .exe, .a, .so and .dll are all binaries. We don’t have a special type of repository for those files because the repository types are per indexing system; not per file type. It’s really about which tool you use to deploy and resolve those files. For example, if you use Gradle, you’ll need to a repository in Maven format, or if you just issue HTTP calls from your scripts, a Generic repo will be the best fit.

 

Question: Is there a way in Docker to see the mappings from ports to repos?

Answer: For the default mappings, you can always consult our User Guide. For custom mappings that you add to your NGINX configuration, you’ll probably have to look at the NGINX config files to figure out the mappings.

 

Question: Can you actually trigger a folder download (and not only file download)?

Answer: Yes, it’s available in Artifactory 4.1. Please note that it is disabled by default.

 

Have a question? Send it to us at webinars@jfrog.com