maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 20:22:10 GMT
I haven't faced these issues myself, but some colleagues contacted me  
about it.
It occurred due to an unstable proxy/network and they knew enough to know  
how to switch between the Artifact Repository and connecting to Maven  
Central directly. From that moment on they were doomed.
So a good message to explain why the build failed is one.
But more important to me: How should you fix it? IMHO removing the  
_maven.repositories is a dirty workaround. If Maven could confirm that an  
artifact from repoA is exactly the same as the one from repoB, then the  
build shouldn't fail if repoA was unavailable, right? If so, I think this  
final step is missing.

Robert

Op Mon, 04 Feb 2013 18:03:14 +0100 schreef Jason van Zyl <jason@tesla.io>:

>
> On Feb 4, 2013, at 11:43 AM, Nicolas Delsaux <nicolas.delsaux@gmail.com>  
> wrote:
>
>> On Mon, Feb 4, 2013 at 5:14 PM, Jason van Zyl <jason@tesla.io> wrote:
>>>
>>>
>>> If you have no proxy and you are all just pointing at Maven Central  
>>> then this particular feature will not affect you. Maven, with no  
>>> mirrorOf configuration in a settings.xml, will follow the repositories  
>>> listed in the POMs. If you several settings.xml files and switch  
>>> between them you may potentially have issues.
>>
>> Well ... it appear that, most of the time, I've got issue not by
>> switching my settings.xml, but rather with a remote repository (not
>> maven central) being down.
>>>
>>> I'd be interested in looking at your configuration as this safeguard  
>>> only results in failure when an artifacts are not available remotely.
>>
>> I'm using as remote repositories (the ones with troubles)
>>
>> * http://repository.sonatype.org/content/groups/flexgroup/ (use as
>> example artifact com.adobe.flex.framework:flex-framework:3.4.0.14408)
>> * http://tinkerpop.com/maven2 (use as example artifact
>> com.tinkerpop.blueprints:blueprints-core:1.1)
>>
>> Both these repositories may sometimes be down, in which case my build
>> fail, ignoring my locally downloaded artifacts.
>> What I find personnally annoying is the fact that maven successfully
>> downloaded these artifacts before, so why not use locally cached ones
>> ?
>
> The underlying assumption is that if they just randomly go away, that it  
> may be permanent and that it won't work for anyone else and considered a  
> failure. The aggregate downtime for RSO (repository.sonatype.org) is  
> very little so that one surprises me. I don't know anything about the  
> older Tinkerpop artifacts but they would probably put the older stuff in  
> Central if we asked. So this is not normal that remote repositories are  
> failing so often that this appears frequently in your builds. But the  
> result internally would be that if it were a developer that were  
> starting from scratch it would fail for them.
>
> While repository managers like Nexus OSS are free, I realize it takes  
> time and energy to install one it is a valuable investment. Anyone being  
> onboarded in an environment where connections to repositories are  
> unstable are going to encounter failures even if you disabled this  
> feature. But agreed, in unstable network conditions without a repository  
> manager you're going to have issues.
>
> How frequently does this happen?
>
>
>>
>>>
>>> I have an implementation that does stronger identification checking.  
>>> But this kicks in after Maven has determined there is something by  
>>> that GAV available remotely and is not something you'll be affected by  
>>> because it's not a publicly available feature. > Again, the  
>>> description for this particular feature:
>>>
>>> ---
>>>
>>> The feature verifies that the remote repositories configured for the  
>>> current build can be used to successfully resolve the artifact in  
>>> question. If you retrieved an artifact in the past from Central and  
>>> now changed your build to only know about Nexus and it doesn't have  
>>> any knowledge of that artifact then the build is going to fail. Put  
>>> differently, if you purged your local repo, your build won't work  
>>> either. Neglecting offline mode, the goal is to ensure that the  
>>> resolution works if it could be performed using a clean local repo  
>>> with the current configuration. Giving confidence that co-workers can  
>>> reproduce the build and not depend on some artifact magically being  
>>> pulled down into your local repository in the past which is nowhere to  
>>> be found in the configured remote repository.
>>>
>>> ---
>>>
>>> Make sense?
>>>
>> In a sense. But if so, why keeping a local repository ?
>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> Selfish deeds are the shortest path to self destruction.
>>>
>>> -- The Seven Samuari, Akira Kurosawa
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Nicolas Delsaux
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> We all have problems. How we deal with them is a measure of our worth.
>
>  -- Unknown
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message