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:
Behind the scenes, Artifactory uses a JSR-170 compliant Java Content Repository (JCR) for storage, using the Apache Jackrabbit implementation. This natural fit makes it extremely easy to manage fully indexed and searchable metadata and to provide full repository coherence with extended features such as security, transacted operations, auditing, locking, etc.
Artifactory's rich Ajax web UI is based on the excellent Apache Wicket web framework.
The standard standalone distribution is using the Jetty servlet container for quick out-of-the-box startup, but it can just as easily be deployed on any servlet container.
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.
Of course not. This is why we created the Import/Export/Backup features, to allow Artifactory users to create a standard file-system based Maven 2 repository layout of the Artifactory DB repositories.
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. When following the standard practice of running continuous builds using a build server, the Artifactory caches would normally be repeatedly synchronized, achieving similar effect to that of mirroring.
Artifactory uses the friendly Apache License, Version 2.0.
By submitting a request to JIRA.
At the moment, only HTTP(S)-enabled remote repositories are supported, including WebDAV repositories. We see HTTP as the primary repository protocol which is used in 95% of the cases and at the moment do not have concrete plans to support other protocol types.
Artifactory supports both Maven 2 and Maven 1 remote repositories. The client is assumed to be a Maven 2 client. We do not support Maven 1 clients, nor we intend to.
Artifactory comes with a pre-configured default "admin" account. Username: admin, Password: password.
Simply download the source and run
mvn clean install from within the Artifactory root module (parent").
To gain access to open source dependencies not currently deployed on Maven's public repositories, you have to run mvn with the "jfrog" profile activated. e.g.:
mvn clean install -Pjfrog.
Just change the right line in the
$ARTIFACTORY_HOME/etc/log4j.properties file to:
Because doing so normally promotes an unmanageable build environment.
In practice, unique snapshots are never tracked for the real changes they carry: the snapshot's final name is not human deterministic and its "meaning" is normally obscure to developers since, by itself, it has no relation to the source it has been compiled against. Moreover, many times snapshots in a multi-module environment are dependent on other snapshots, so you would have to reconstruct by hand a cryptic dependency chain just to get back to a version you believe is stable. Often, the identification process of such a version is, by itself, obscure and is based on common inputs such as "yesterday before lunchtime everything worked"
Therefore, it is highly preferable to use non-unique snapshots in development and, when needing, go back to a stable non-snapshot version by reconstructing one from a specific revision/tag in the VCS, where the meaning of the artifact can be easily tracked. It is advised to have the artifact itself embed the revision/tag (as part of its name or internally) for clear and visible revision tracking.
We are doing our best to maintain full cross browser behavior, but our resources are limited, so Firefox an IE 7 always come first. It is strongly recommended to upgrade to one of these browsers.
Try adding the following directive to you Apache configuration:
Stop Artifactory, delete the
$ARTIFACTORY_HOME/data/jcr/workspaces/default folder and restart Artifactory. Be patient, as it might take some time for Artifactory to rebuild its indexes, depending on the repository size.
To login use the read-only "guest" account. Username: guest, Password: guest.
Nothing is. Being on a public demo, the "guest" account is a limited read-only account.
If you wish to use administrative or experiment with privileged operations please download and install a local instance of Artifactory.