geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Maven Repo Woes - Temporary resolution in place
Date Wed, 07 Jun 2006 23:57:17 GMT
Just for the record, whatever our temporary solution is, it's not
working.  I'm running an online build and it's been hung for like 5
minutes trying to download an ActiveMQ JAR from, and now
it's moved on to the next ActiveMQ JAR and it's hung again.  I had to
whack mortbay from the list to get it to move at all.

I think the only way to avoid this with Maven 1 is to put everything
in one repository and make that the only entry in our repo list.
While it's nice to have backup sites in theory, if is
causing timeouts, if I understand this right we're going to suffer
that lag on every SNAPSHOT (which is 99% of our downloads --
geronimo*SNAPSHOT*) since I believe for a SNAPSHOT Maven checks all
the repositories in the list.

Will the infrastructure team be peeved if we put everything in our
Solaris zone and make that the sole build repository for Geronimo?  I
don't know if the objection is to the level of traffic directed to or the level of traffic in general.

Craig, to clear this up for you, in a typical Geronimo build, we
create over 100 artifacts, which are all SNAPSHOTS.  Every artifact
has at least one other module that depends on it.  With Maven
1.1-beta-2, the first time in a build that Maven finds a SNAPSHOT that
it hasn't already downloaded in the current build, it tries to
download the latest from (if I'm right above) all defined
repositories.  It does not understand that it just built that module,
it tries to download it anyway.  So we are guaranteed 100+ download
attempts, times 5 repositories, or 500+ snapshot downloads per online
build.  Often, a repository (like mortbay above) is down in such a way
to cause timeouts, which are on the order of minutes (there are
apparently some retries involved), and you get that timeout for all
100+ snapshot downloads (making for a several hundred minute delay
time on top of the normal build time).  We can't remove everything but
ibiblio from our list because we normally depend on SNAPSHOT releases
of openejb, axis, activemq, tranql, jetty, and more, and those aren't
in any one repo (certainly not on ibiblio).  We also can't expect all
Geronimo developers to maintain and build all those projects in order
to build Geronimo.

It seems like Maven 2 will help somewhat, between reduced SNAPSHOT
downloads and mirror capability.

Still, it's extremely unfortunate that your very first build as a
developer is the absolute worst-case scenario.  It would be very nice
to have an updated "Maven repo bundle" that a new developer could
download (or check out) and unpack to get all the dependencies in one
shot so their first build could be offline (or at least faster).


On 6/7/06, Craig L Russell <> wrote:
> Apologies in advance if this is noisy. I've been using maven for only
> a year, so I don't understand all the issues.
> Maven will cache artifacts locally and if you have a dependency on a
> non-snapshot version of the artifact, it only ever gets downloaded
> once. From then on, it assumes that the version in your local
> repository is current. Right?
> If you have a dependency on a snapshot version it will attempt to
> download it from a remote repository, which you can define to be e.g.
> ibiblio to completely bypass any use of apache resources. (Of course,
> this means that it increases the load on ibiblio but they've signed
> up to be an apache mirror so they presumably know the drill).
> The way we use maven is that the snapshot version dependencies are on
> artifacts that can be built locally; that is, they just don't exist
> on the remote repository, so maven can't find them remotely. This
> can't be much of a load. Returning a 440 reply to a maven request
> isn't expensive... Right?
> I'm sure I'm missing something obvious, and I would like to know
> where I've gone off the rails...
> Thanks,
> Craig
> On Jun 7, 2006, at 12:57 PM, Henri Yandell wrote:
> > On 6/7/06, Joshua Slive <> wrote:
> >> On 6/7/06, Henri Yandell <> wrote:
> >> > On 6/7/06, Joshua Slive <> wrote:
> >> >
> >> > > And in any case, I believe that much of the problem
> >> > > is not with maven per se, but with how it is being used.
> >> >
> >> > How exactly?
> >> >
> >> > Cocoon/Geronimo have both hit the same problem.  The factor
> >> would seem
> >> > to be having a lot of components in your build - which I can't
> >> see as
> >> > being a mis-use.
> >>
> >> The part about pointing to as a maven repository is
> >> not a design flaw in maven.  The part about maven gobbling up way
> >> more
> >> resources than necessary probably is.
> >
> > Geronimo/Cocoon and other projects did not set up the maven snapshot
> > repository at the ASF, they're using what has been in place for a long
> > time.
> >
> > Hen
> Craig Russell
> Architect, Sun Java Enterprise System
> 408 276-5638
> P.S. A good JDO? O, Gasp!

View raw message