I am doing some research on Apache Archiva and Artifactory. So, actually i am not finding exact information about apache archiva and artifactory supporting following features or not:
1) load balancing
2) Nuget
3) Redhat and CentOs
4) Ease of Backup and disaster recovery
5) LDAP mapping to local defined users.
So, please tell does all these features are supported by apache archiva and artifactory? It will be of great help.
A good place to start will be the Binary Repository Manager Feature Matrix which contains highly detailed comparison of Artifactory, Archiva and Nexus.
Related
I have nexus installed behind of apache server. apache is configured to use SSO, it's triggered in the apache level and then I pass uid through headers.
the problem is that does not work when I want to deploy to nexus with maven.
Have you any idea please
Regards
We are currently moving from Nexus 2 to Artifactory.
While Nexus 2 had dedicated support for Maven Sites, Artifactory has not.
I guess that I could deploy Maven Sites to an Apache HTTP Server, a Tomcat or anything similar, but I am not sure.
What are the prerequisites for using a server as a "Maven Site server"?
The following seems to work:
Install a Apache httpd on a Linux system. Configure the www directory.
Use scp to deploy the site to the defined www directory.
For scp, you need the wagon dependency for ssh and an appropriate user for your Linux server.
I am new to web hosting.
I want to use an Apache HTTP server to host the site for my artifact built with Maven.
Since Maven uses protocols like SCP, what else should I require to configure the system?
How should I configure the system so that my artifact is available on my HTTP server?
I could set up Artifactory, but I want to know if it is possible to do so without any other third party artifact management system.
Thanks!
I am using Spring roo.But i found that roo uses internet to download the maven plugins at first time. To avoid it am trying to use Apache archiva Stand alone.But i don know how can i configure it for maven.Can you help me to solve this
Apache Archiva can serve the artifacts you need for Spring Roo, but if you do not have an internet connection from the Apache Archiva server then you have to upload the artifacts yourself.
But if you can get the server connected to the internet once, then you can let the archiva server download the artifacts for you, because it can act as a proxy and then caches the artifacts. Once connected to internet, let Spring Roo retrieve the artifacts from the Archiva server. When you have done this one time, archiva should have cached the artifacts. Then you could disconnect it from the internet.
If you want to know how you can configure maven to use the Apache Archiva repository, look at:
http://archiva.apache.org/docs/1.0.1/userguide/using-repository.html
We have a public Sonatype Nexus Maven Repository which is a proxy for several third-party repositories, such as JBOSS or the Scala-Repo.
Does the downloading of artifacts which are located in one of the proxied repositories (JBOSS for example) produce traffic on the sever which runs our repository?
Here is what happens for released artifacts (SNAPSHOT would involve more checks):
Client Machine: Do I have a dependency in my local repository? If yes, use it. If no, try to download it from a remote repository (Nexus here).
Nexus: Do I have the artifact? If yes, serve it to the client. If no, try to get it from a known third-party repository, store it and serve it.
Third-party repository: Do I have the artifact? If yes, serve it to the client (Nexus in this case). If no, send 404.
So, there is potentially traffic between the client machine and Nexus and there is potentially traffic between Nexus and a third-party repository. If this doesn't answer the question, please clarify.
Yes it can, particularly for snapshots and whenever maven asks for the maven-metadata.xml (which is used in snapshots or version range resolution). This can be optimized using routing rules to prevent for example com/yourcompany from ever being resolved from jboss or central etc.