[ImageJ-devel] Speeding up Maven downloads using the ImageJ public mirror

Curtis Rueden ctrueden at wisc.edu
Fri Jan 17 11:23:04 CST 2014


Hi Dscho and everyone,

> It is a pity that we cannot configure the mirror from the pom-scijava
> parent (which would have relieved every developer from having to
> configure the *exact* *same* thing on their computers), but at least
> it is easy enough.

For what it's worth, what we *can* do is switch pom-scijava to use the
ImageJ "public" group (http://maven.imagej.net/content/groups/public) as
the sole repository. This means by default, everyone's Maven builds check
only two repositories: Central and ImageJ public. Further, if/when we need
to introduce access to additional repositories and/or remove obsolete ones,
we don't have to hack the POM anymore; we can just update our Nexus
configuration. That way everyone automatically benefits from such changes
with no action required.

Until recently, our Nexus was also misconfigured to not do proper
bookkeeping: it was not updating its indices or emptying its trash. Now
that I have things set up correctly, everything is kept up to date, and the
mirror feature Johannes mentioned works for developers who care to
configure it in their ~/.m2/settings.xml.

Regards,
Curtis


On Wed, Jan 15, 2014 at 11:35 AM, Johannes Schindelin
<schindelin at wisc.edu>wrote:

> Hi Curtis,
>
> I got curious about the "remote proxy" feature of Nexus (which is used to
> serve ImageJ's Maven repository). For the benefit of other developers, let
> me write it up here:
>
> When clicking on the "Repositories" link on the left hand side menu of
> http://maven.imagej.net/ you see a lot of repositories with basically
> four types: "group", "hosted", "virtual" and "proxy":
>
>         http://maven.imagej.net/index.html#view-repositories
>
> The "hosted" ones are our repositories, to which we deploy: snapshots,
> releases and thirdparty (for dependencies we rely on that were not
> deployed anywhere yet).
>
> The "virtual" repositories are there only for compatibility and we could
> even switch them off because we do not support Maven 1 at all.
>
> The proxy repositories are interesting: when accessing them via Maven,
> they try to retrieve the desired artifacts from remote repositories and
> keep cached copies (eternally for release versions, 24 minutes for
> snapshots) so that they serve the artifacts from the cache until expired.
>
> The groups are just aggregating others, and the most important group is
> the "public" one: it offers a single, public-facing repository that serves
> *all* of the public repositories, including the proxy ones.
>
> Now, the real cool thing about it is that you can configure your local
> Maven to use the "public" group repository as a *mirror*, i.e. instead of
> looking here and there and everywhere for artifacts, it looks only at the
> "public" repository and lets that one worry about retrieving the
> artifacts. It also makes things faster because Maven will only have to
> look at one single repository rather than trying a couple of them.
>
> To configure the mirror, I added the <mirrors> section to my
> $HOME/.m2/settings.xml:
>
> -- snip --
> <settings>
>         ...
>         <mirrors>
>                 <mirror>
>                         <id>imagej-mirror</id>
>                         <name>ImageJ's public mirror repository</name>
>                         <url>http://maven.imagej.net/content/groups/public
> </url>
>                         <mirrorOf>*</mirrorOf>
>                 </mirror>
>         </mirrors>
>         ...
> </settings>
> -- snap --
>
> It is a pity that we cannot configure the mirror from the pom-scijava
> parent (which would have relieved every developer from having to configure
> the *exact* *same* thing on their computers), but at least it is easy
> enough.
>
> Maybe we should teach the imagej-maven-plugin to edit the user's
> configuration when the user asks for it?
>
> Ciao,
> Dscho
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140117/ce56828f/attachment.html>


More information about the ImageJ-devel mailing list