|
|
General Questions- What problems does Artifactory solve?
-
We found out that, when working with Maven artifacts, most organizations need to
have a reliable artifacts proxy service in place, for the following reasons:
-
The public Maven repositories can become unreliable from time to time
(down, highly busy, slow...). It is also not uncommon for broken or
wrong artifacts to appear on these repositories.
This unexpected behavior can fail the build and/or lead to
non-reproducible build results, which for most enterprises is a must.
-
It is expensive and inefficient for every developer inside the same
organization to go and retrieve remote artifacts that are shared by nature.
-
Without a mesh of proxies, there is no easy way to automatically share
artifacts in multi-site development environments.
-
There is often a need to globaly enforce and control the repositories
and the artifacts included in a build in terms of: security, licensing,
include/exclude patterns (do not look for inhouse artifacts
on repo1), etc. This can only be achieved by a global proxy.
-
As part of a normal build Maven will send update queries to its public
repositories, even for organization internal artifacts. Such query
requests going over the internet may reveal sensitive information about
your ongoing projects, which the organization would like to keep
private. Using Artifactory's include/exclude patterns allows you to
avoid internal artifacts from being queried on the internet.
- Why Artifactory? What's wrong with Maven Proxy or with similar offerings?
-
We created Artifactory after using the legacy Codehaus Maven-Proxy project.
We soon found out we needed to have many bug fixed as well as additional
advanced features implemented, such as security, indexing, web-based deployment,
multiple local repositories, etc.
After playing with the existing codebase, we soon realized that we are
refactoring and changing too much than can be submitted as patches, so we
decided to go and create Artifactory.
In fact, Artifactory still carries some excellent concepts and implementations
from the original Maven Proxy.
- With a database used for artifact storage, won't I be loosing control over my
repository?
-
On the contrary. Using JCR and a DB for storage not only offers a superior
technical solution, but also allows for greater control over your repository.
Artifactory provides browsing, deploying and undeploying through
an Ajax web UI which allows doing all common administrative operations in a
security-aware fashion.
Additionally, if you wish to import or export your repositories to the file
system or execute scheduled backups of your repositories to regular file system
directories, Artifactory allows you to do that.
- After using Artifactory with Derby DB for storing my artifacts will I be
forced to use Artifactory forever?
-
Of course not. This is why we created the Import/Export/Backup features, to
allow Artifactory users to create a standard file-system based Maven2 repository
out of the Artifactory DB repositories.
- Does Artifactory provide mirroring?
-
No. Artifactory uses controlled caches of remote repositories, not mirroring.
Caches are populated lazily upon request, so it is only when Maven starts
hitting it with requests that caches start to fill up with artifacts.
Indexing is done completely by Jackrabbit and, unlike with mirroring, is up to
date immediately.
- Under what license is Artifactory distributed?
-
Artifactory uses the friendly Apache License, Version 2.0.
- How can I report a bug or ask for new features?
-
By submitting a request to
JIRA
.
- What protocols can be used to proxy remote repositories?
-
At the moment, only HTTP(S)-enabled remote repositories are supported (including
other Artifactory repositories). We do not have concrete plans to support other
types of protocols.
- What Maven repository formats are supported?
-
Artifactory supports only Maven 2 repositories. Maven 1 repositories are
becoming rare and are not supported natively (but are usually proxied as Maven 2
repositories by Apache httpd).
- How does Artifactory resolve artifacts?
-
Artifactory always looks up artifatcs in the following order:
- Local repositories
- Remote repository caches
- Remote repositories
The iteration between repositories (of the same type) is by the order they are
decalred in the configuration.
As of version 1.2.1, Artifactory supports only the following built-in
aggregation schemes:
-
A global virtual repo of all local repositories + all remote
repositories and their caches.
Using the URL: :/artifactory/repo]]>
-
Any single local repository + all remote repositories and their caches.
Using the URL: :/artifactory/]]>
-
Any single cache repository + all remote repositories and their caches.
Using the URL: :/artifactory/-cache]]>
We are working on adding support for virtual repositories, which will allow you
to for aggregate any set of local and remote repositories under an alias, and to
use that alias as a virtual repository.
|
|
|