Best practices for setting up an ivy repository se

 I looked around for a while, but I didn't see any tutorials on how to
> set up a repository server: how to configure the http server so that
> modules can be easily updated on the server, etc. Does anyone have any
> recommendations for how to do this? It doesn't need to be very fancy;
> right now there's only one module that needs to be shared between a
> couple projects.

To the best of my knowledge, the closest thing I can think of to such a
tutorial is a piece of advice on the "Best Practices" page in the Ivy docs.
See the section "Use your own enterprise repository:"
http://ant.apache.org/ivy/history/trunk/bestpractices.html

What might be helpful, in an indirect way, is the tutorial on adjusting your
enterprise's ivysettings.xml:
http://ant.apache.org/ivy/history/latest-milestone/tutorial/defaultconf.html
When you get right down to it, how you set up your enterprise repository
server(s) is intimately tied to how you establish your Ivy settings,
although, to be fair to your point, the latter is more a description of the
former.

Anyway, when deciding how to expose an Ivy repository (repositories), I can
think of a few decision parameters.

One is which kind(s) of repository to use. By kind, I mean what scope it
has. One kind is a shared repository, one that's used by everyone in a team
or enterprise. This sounds like what you're looking at using. But in
addition you might configure a local repository, on each developer's
machine, and a public repository out on the web. The typical precedence, as
configured in ivysettings.xml, would be:

   1. local
   2. shared
   3. public

The page I linked to touches on this. I'll come back to public repositories
later.

Another parameter is protocol. Assume we're talking strictly shared
repositories:
* What protocol will I use to download modules via the ivy:resolve Ant task?
I think the most common is HTTP, although filesystem access shouldn't be
discounted.
* What protocol will I use to upload modules via the ivy:publish Ant task?
I'm not sure which is most common; I'm familiar with FTP and filesystem. If
it's filesystem and your Ivy server is on a Unix machine while your dev
machines and CI machine are Windows, then you're going to have to deal with
Samba.

There's another protocol I can think of. Suppose you're using Subversion for
version/source control. You could expose a Subversion repository as an Ivy
repository via the IvySvn dependency resolver:
http://code.google.com/p/ivysvn/

But this gets into another decision parameter. What is the relationship
between the Ivy repository and source control? I don't like the idea of
exposing a Subversion repository as an Ivy repository because it blurs the
line between source code and build artifacts, but I can understand why some
would consider it a nice shortcut.

Another source of variation I've seen is to place module artifacts in one
repository location and module ivy.xml files in another. As far as I know,
this might come into play when you're using a public repository and don't
have the ability to customize the Ivy files.

All these decisions get expressed in the Ivy settings you use. The
ivysettings.xml file really is the descriptor for your whole Ivy repository
landscape.

Finally, there is one decision that doesn't necessarily get expressed in the
Ivy settings. That is how to deal with third-party modules, as opposed to
in-house modules. This is where public repositories can be helpful.

You might use a public repository directly, or--if you follow the above
advice on the "Best Practices" page--you would copy the public repository's
contents to your own shared repository using the ivy:install Ant task. I
don't want to take sides in this message on the question of whether to use a
public repository directly, but I would say, if you do use a shared
repository for third-party dependencies, it makes life a little simpler if
you try to make it as consistent as possible with the public repositories
already out there. For example, for an Apache Commons project, use
organisation "org.apache.commons" as opposed to "apache." Now, if you create
your own repository by copying an existing public one, you'll get this
consistency for free.