I am working with Nexus free addition (1.3.6) and I am trying to add a proxy repository as described in the Nexus book - Google Caja: http://google-caja.googlecode.com/svn/maven.
After adding a new proxy repository and configure the remote location, I tried to re-index the repository but could not see the related artifacts.
was anyone able to proxy a remote repository via Nexus and see its artifacts?
Ronen.
Well, according to the Nexus documentation about Remote Index Downloads:
Nexus ships with three important proxy
repositories for the Central Maven
Repository, Apache Snapshot
Repository, and the Codehaus Snapshot
Repository. Each of these repositories
contains thousands (or tens of
thousands) of artifacts and it would
be impractical to download the entire
contents of each. To that end, most
repositories maintain a Lucene index
which catalogs the entire contents and
provides for fast and efficient
searching. Nexus uses these remote
indexes to search for artifacts, but
we've disabled the index download as a
default setting. To download remote
indexes,
Click on Repositories under the Administration menu and change
Download Remote Indexes to true for
the three proxy repositories. You'll
need to load the dialog shown in
Figure 5.9, “Repository Configuration
Screen for a Proxy Repository” for
each of the three repositories.
Right-click on each proxy repository and select Re-index. This
will trigger Nexus to download the
remote index files.
It might take Nexus a few minutes to
download the entire index, but once
you have it, you'll be able to search
the entire contents of the Maven
repository.
Once you've enabled remote index
downloads, you still won't be able to
browse the complete contents of a
remote repository. Downloading the
remote index allows you to search for
artifacts in a repository, but until
you download those artifacts from the
remote repository they will not show
in the repository tree when you are
browsing a repository. When browsing a
repository, you will only be shown
artifacts which have been downloaded
from the remote repository.
So, to me, the proxyed remote repository has to provide a Nexus Index (which does not seem to be the case of the repository for Google Caja) to allow searching and searching is different from browsing (i.e. you'll still have to download artifacts to see them when browsing the repository). That being said, not providing an index doesn't mean the caja repository isn't proxied.
Related
I'm trying to convince the higher-ups at my work place to migrate to Apache Ivy. I've managed to get a few sandbox projects working using Ivy to power the build, and now I have a greenlight to put together a migration proposal.
We all agree on one thing: we don't want to trust JARs that are located in public directories! I know, I know, a bit paranoid, yes. But we'd like to have a setup where we pull a JAR from a trusted source (either downloading it from the open source project itself, or most likely, gulp, a public repo), and use it for some time before we "certify" it (give it our blessing as a safe artifact to use).
Then we want to have a common repository for all JARs used by our many projects.
My original thinking was to place this repository up in version control (we have an SVN server). But I wasn't sure what best practices dictate. It might make more sense to put our JARs on a file server and FTP to them in the Ivy script.
Either way, SVN (HTTPS) or FTP, all of our servers are authenticated. So, a small number of questions:
Where should we be publishing all of our "certified" JARs (everything from `log4j` to any homegrown JARs we produce)? What do best practices dictate?
The "ivyrep" resolver-type does not take username or passwd atrributes. If our "JAR server" (FTP, SVN, etc.) is authenticated, how do I configure the Ivy scripts to login?
I must echo Brian's recommendation to use a repository manager like Nexus. It's a lot less work in the long run. You'll also discover that the professional version of Nexus enables you to create approval processes around repositories which you plan to use in your build. See the procurement suite functionality.
If, on the other hand, you are determined to build your own repository, then ivy has the tools for the job. You need to become very familiar with the ivy settings file and how it declares and uses resolvers.
If repository is accessible via HTTPS the the url resolver should be able to access it. The resolver will assume that each version of an artifact is in a different directory and you'll need to specify the URL pattern that ivy will need to use when accessing the repository:
<url name="two-patterns-example">
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
The pattern is fully flexible to how you store the artifacts.
Authentication is also handled in the settings file using the credentials tag.
Finally, the FTP protocol is also supported. It's hard to find in the doco, but it's supported by the vfs resolver.
I think that's enough information on an option I don't recommend :-) Having said that I once created an FTP based repository for managing releases to clients. It's useful to have a tool this powerful :-)
Why not use something like Sonatype's Nexus. I've seen it used for Maven, and I believe it'll work for Ivy.
You can set it up to download from remote repositories into (say) a 'test' repository. You can then evaluate those .jars, and if they're good, upload them into an 'approved' repository for general consumption. There's some authentication surrounding this, but you'd have to evaluate that in greater depth. Certainly you can restrict the uploading into repositories via a username/password pair.
Is there any simple way,which is provided by maven itself, to open my local repo as a remote one for other users?(How cool it would be;) )
Or should I install an ftp server or apache to do it?
This is not straightforward. What you are looking to do is to set up a mirror of the repositories to be used by other users. You will be better of setting up one of the repository managers to do this.
I think this was supposed to be a simple task, but I've been unable to accomplish it.
I've set an archiva repository as this:
2 Internal Maven1 repos (old projects)
1 Internal Maven2 repo
7 Remote repos (central, java.net, jboss.org, etc.)
For each internal repo I've created a proxy connection with each remote repo.
I've added a new mirror to my settings.xml file as explained in the archiva documentation:
<mirror>
<id>archiva.default</id>
<url>http://repo.mycompany.com:8080/archiva/repository/internal/</url>
<mirrorOf>*</mirrorOf>
</mirror>
When I try building a simple project with one dependency from some of the remote repositories, no artifacts are downloaded. Why?!?
Thanks for any help.
Archiva doesn't assign repositories any special roles. You make requests to specific managed repository from Maven (so from your settings, internal), and it will serve what is in there, or proxy it from remote repositories that have been connected by a proxy connector. By default, that is just Central - adding a new remote repository has no effect until it is connected to a managed repository by a proxy connector.
What you probably want to do is add a proxy connector on the internal repo to the remote repositories in question. Consider setting the whitelist too so that it is more effecient.
You may also want to set up a repository group that spans all the managed repositories (both maven 1 and maven 2) for use from a single URL.
I had exactly the same problem with Archiva 2, for me the solution was to give the "Global Repository Observer" role to the Guest user.
The nexus book: http://www.sonatype.com/books/nexus-book/reference/. Does not seem to spend any time on how one should go about backing up a nexus repository. If I am installing my snapshot and releases into this local repository, it seems that it would behoove me to back it up. However, I'm not really interested in backing up anything that can easily be downloaded from a remote repository.
Some google searches do not seem to reveal the canonical answer either, so perhaps for posterity it can be recorded here.
Thanks,
Nathan
When you install Nexus, you'll end up with two directories:
nexus-webapp-1.3.1.1/
sonatype-work/
We've separated the application from the data and configuration. The Nexus application is in nexus-webapp-1.3.1.1/ and the data and configuration is in sonatype-work/nexus. This was mainly done to facilitate easier upgrades, but it also has the side-effect of making it very easy to backup a Nexus installation.
The Simple Answer
Nexus doesn't store repositories in a database or do anything that would preclude a simple backup of the file system under sonatype-work/nexus. If you need to create a complete backup, just archive the contents of the sonatype-work/nexus.
Better Answer
If you want a more intelligent approach to backing up a Nexus installation, you will certainly want to backup everything under sonatype-work/nexus/conf, sonatype-work/nexus/storage, sonatype-work/nexus/template-store. If you want to backup the metadata and file attributes that Nexus keeps for proxy repository, backup sonatype-work/nexus/proxy, although this isn't required as the information about the proxy repository will be generated on-demand as attributes are requested.
You don't need to backup sonatype-work/nexus/logs and you don't need to backup the Lucene indexes in sonatype-work/nexus/indexer.
Nexus Pro Answer
There is a Nexus Professional plugin which can automate the process of creating a backup of the Nexus configuration data. This plugin is going to address the contents of the sonatype-work/nexus/conf directory. If you need to backup the sonatype-work/nexus/storage directory, you will need to configure some backup system to backup the contents of that filesystem. Once again, as with Nexus Open Source, there is currently no real benefit in backing up the contents of sonatype-work/nexus/indexer or sonatype-work/nexus/logs.
Excluding Storage for Remote Repositories
In your question you mention that you want to exclude the storage devoted to the local cache of a remote repository. If you are interested in doing this, you'll have to take a further level of granularity and just exclude the directories under sonatype-work/nexus/storage that correspond to the remote repositories.
Do you need to shut Nexus down for a backup?
Brian Fox told me no, the only real chance for file contention is going to be the files in the indexer/ directory. You shouldn't have a problem backing up the sonatype-work filesystem with a running instance of Nexus.
BTW, thanks for the question, this answer will likely be incorporated into the next version of the Nexus book.
afaik nexus (free version) does not have any backup features, but it should be as simple, as knowing your companies groupId and grabbing it from the storage directories in nexus
but i would schedule a complete repository backup too, you never know when the remote repositories are down, when you need them the most
I would like to host a Maven repository for a framework we're working on and its dependencies. Can I just deploy my artifacts to my FTP host using mvn deploy, or should I manually deploy and/or setup some things before being able to deploy artifacts? I only have FTP access to server I want to host the Maven repo on.
The online repository I want to use is not hosted by myself. As I say, I only have FTP access, so if possible, I would like to use that FTP space as a Maven repository. The tools mentioned seem to work when you have full control over the host machine, or at least more than just FTP access since you need to configure the local directories where the repositories will be placed. Is this possible?
You might want to have a look at Nexus, a Maven repository manager. We've replaced our local Maven repository with a Nexus-based one and find it tremendously useful.
I've successfully used Archiva as my repository for several years ... see http://archiva.apache.org/. It's easy to administer and allows you to configure as many repositories as you need (SNAPSHOT, internal, external, etc).
According to the book "Better Builds with Maven", the most common type of repository is HTTP, this paragraph describes what I think you need:
This chapter will assume the repositories are running from http://localhost:8081/ and that artifacts are deployed to the repositories using the file system. However, it is possible to use a repository on another server with any combination of supported protocols including http, ftp, scp, sftp and more. For more information, refer to Chapter 3.
A Maven 2 repository is simply a specific directory structure, so once you get the transport and server specifications right for the repository and deployment portion of your POMs, it should be completely transparent to your users.
You can even use Dropbox. All that you need is a public address to access the files generated with mvn deploy, with any of the protocols in the accepted answer.
I guess there are more services that can work in the same way, but I'm not certain about the URL schemes that alternatives to Dropbox may use.
https://maven.apache.org/wagon/wagon-providers/wagon-ftp/ will tell you that you can use ftp to read from an existing repository, but not to create a new one. I don't think that it is impossible in principle, but no one has cared to write all the fiddly code to do the directory management via ftp.