maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Pain with MNG-5181 (_maven.repositories)
Date Mon, 04 Feb 2013 20:24:22 GMT
I think my case was network issues due to an unstable (enterprise) proxy
too.
Le 4 févr. 2013 21:22, "Robert Scholte" <rfscholte@apache.org> a écrit :

> 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/<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<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<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<dev-unsubscribe@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message