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.
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
Please correct me if I am wrong about my understanding of mod_dav_svn, which is that it basically serves 2 purposes:
Expose the SVN repository (on the filesystem) to clients, which can be either:
repository browsers (e.g. web)
the 'svn' command itself, which is a client command line program
Act as a repository browser to make the repository viewable in a convenient way
Now for point 1, are my following assumptions correct?
Anytime a repository is exposed using mod_dav_svn, the http:// or https:// form of accessing the repository is used
If using svnserve, the svn:// form of accessing the repository is used
In this case, mod_dav_svn would serve no additional use
For point 2, if using Trac's repository browsing functionality, there is no additional use for the repository browsing functionality offered by mod_dav_svn?
Does mod_dav_svn serve any other purpose I haven't outlined here? Asked another way, is there any disadvantage to going with svnserve and Trac?
I ask because I get the impression that mod_dav_svn is very commonly used, so I wonder what I'm missing.
Forget Point #2: HTTP Browsing. That's just a slight bonus. It doesn't replace your need for something like Fisheye, ViewVC, or (my favorite) Sventon.
There are some disadvantages of using Apache's http for your Subversion server:
It's slower
It's harder to setup
Then, there are advantages:
It uses a standard port (80) that's not normally blocked by firewalls.
It can be integrated with LDAP and Active Directory
You can use HTTPS which will encrypt updates and checkouts (including user passwords).
You can have multiple repositories use the same Apache httpd instance. With svnserve, you can only do a single repository per instance and if you have multiple repositories on one system, you'll have to run each svnserve process on a non-standard port.
My personal take: If you are doing a corporate environment, the advantages of using the HTTP or HTTPS protocol way outweigh the disadvantages. If you are talking about a small repository and you and your friends, I run svnserve simply because of the lower overhead and easier setup. However, in those circumstances, I just use Github and not worry about it.
I run Subversion as my personal source control system on my machine, and I use svnserve in that instance.
Thanks, some follow up questions. 1) When I access a URL on my svn server as svn://server/repo, isn't that using port 80 as well? 2) If LDAP integration can't be done for svnserve, is the only way users can authenticate is if they're in the file referred to by password-db in svnserve.conf for svn:// or have a shell account for svn+ssh://? 3) Can't the same protection offered by https:// be offered by svn+ssh://, or is there a difference? (Sorry I can't put paragraphs here it submits every time I hit enter am I doing it right.) –
It's using port 3690 by default. This can be changed when you run svnserve, but then your svn URL has to reflect that too.
Pretty much true. Most places that use svnserve use the passwd file. However, since version 1.5, you can use SASL. However, I have never seen anyone use it.
Yes, ssh+svn:// does offer encrypted packets. However, SSH can be tricky to implement. Basically, the svnserve process has to be spawned and run for that particular user. That means each user needs direct read/write access to the repository. You need to setup umask for each user and create a Subversion Unix group everyone belongs to. Then, since these users have direct access to the repository files, keep them from logging onto the repository server. The Online Manual has complete details. But, in the end, it only works on Unix servers and Unix clients. Windows clients don't have SSH on them, and would have to install that. I've tried it a few times, but https:// is much easier.
The simplicity of svnserve makes it a no brainer for quick and dirty installs, especially if you are deploying on Windows.
However, the moment that you need to memorize a lot of passwords, and would wish that the Subversion repository use the same SSO mechanism that is used in the organization, using Apache's authentication mechanisms coupled with mod_dav_svn helps a lot.
Prior to Subversion 1.7, mod_dav_svn's performance was said to be atrocious and known to be slower than svnserve. Subversion 1.7 supposedly offers a faster and simpler HTTP protocol which should make mod_dav_svn use more palatable.
Right now I have a JBoss application server and I want to setup an internal maven2 repository. I want the repository to be located on the application server. How would I go about doing this? Basically I want to host files on a JBoss application server similar to: http://repo1.maven.org/maven2/
I want the repository to be located on the application server. How would I go about doing this?
In that case, your best option is to deploy a Repository Manager like Nexus, Artifactory or Archiva. My preference goes to Nexus.
the easiest way is to deploy archiva on your JBOSS and create the archive through it:
http://archiva.apache.org/