On Fri, May 8, 2009 at 00:28, Brian Fox <[email protected]> wrote:
>
>
> On Thu, May 7, 2009 at 4:31 PM, Asgeir S. Nilsen <[email protected]> wrote:
>>
>> I've set up a local Nexus repository mirroring some central
>> repositories.  I'm using Maven 2.1.0.
>>
>> In settings.xml I've set up the mirror as such, using the new mirrorOf
>> syntax:
>>
>>    <mirror>
>>       <id>Twingine</id>
>>       <name>Twingine Public Mirror</name>
>>       <url>http://localhost:8081/nexus/content/groups/public</url>
>>       <mirrorOf>*,!java.net,!hudson-libs</mirrorOf>
>>     </mirror>
>>
>> This has one major issue:  There is no standard for repository IDs,
>> apart from 'central'.  Different projects use different IDs for the
>> same repository.
>>
>> The result is build failures when the mirror is enabled, because some
>> snapshot repository somewhere down the line has issues.
>>
>> I propose two different strategies for handling this in a more reliable
>> way:
>>
>> 1. Ability to use groupId in the mirrorOf clause
>> ------------------------------------------------------------------
>> You could then state for instance:
>>
>> <mirrorOf>org.apache.maven,org.codehaus.mojo</mirrorOf>
>
> The groups that a repository may contain is not known ahead of time. How
> would you connect these together?

Basically when Maven sets out to resolve a certain artifact, it will
from this clause decide whether to try a mirror first, or just go
directly to normal flow of resolving it through the configured
repositories.

My point is that deciding what to mirror based on repository IDs is
error-prone, since there is no common naming standard or consensus for
any other repository than central.

>
>>
>> or
>>
>> <mirrorOf>*,!com.othercompany</mirrorOf>
>>
>> Default behaviour could be that subgroups would be included, or to
>> have some kind of star syntax.
>>
>>
>> 2. Ability to exclude snapshot repositories from mirroring
>>
>> ---------------------------------------------------------------------------------
>>
>> Either as a default, or as a setting for each mirror clause.
>>
>> For example:
>>
>> <snapshots>
>>  <enabled>true</enabled>
>> </snapshots>
>
> A mirror has the net effect of replacing the url used for lookups. The
> snapshot/release/plugin nature of a given repository is unchanged by the
> mirror entry.

True.  I was more interested in having a mirror configuration where
only release repositories would be considered eligible for mirroring.
>From my settings snippet above you see that I try to mirror everything
part from a few known repos with issues.

Having the ability to exclude any snapshot repository from mirroring
could be helpful in this context.

>
>>
>> Or even a snapshot expiry:
>> <snapshots>
>>  <enabled>true</enabled>
>>  <updatePolicy>interval:30</updatePolicy>
>> </snapshots>
>>
>>
>> What do you think?
>
>
> Complex scenarios like this are generally handled by repository
> managers: http://maven.apache.org/repository-management.html

Agreed.  And I do try to handle this complexity through using Nexus.
However, using Nexus with a <mirrorOf>*</mirrorOf> introduces other
complexities, and I'm suggesting a way to strike a balance.


Just thought of a third option:

3. Fall through to actual repository if mirror lookup fails
------------------------------------------------------------------------------

For a given artifact, possibly only valid for snapshot artifacts, if
looking up the artifact through the configured mirror(s) fail, try
contacting the actual repositories instead.

Asgeir

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to