Anders, I am researching my project/repository against your explanation. I will follow up with a real answer once complete. Thanks for your response.
On Mon, Feb 5, 2018 at 3:25 PM, Anders Hammar <and...@hammar.net> wrote: > I'd like to stress that my explanations are from what I recall. I could be > wrong. > > If my memory serves me right and this is how it works, I believe it was > just to prevent the scenario you're describing (switching between different > repos) from causing the wrong result. The idea was then that if you change > your repo/mirror config, your intention is to use the current declared > repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used. > However, using the repo/mirror id is probably not the best solution; using > the url would probably be better. > > So, in your scenario, you typically work with a corporate proxy/mirror > (like Nexus) that only gives you access to procured artifacts. Then you > want to use/test some artifact that the mirror don't allow, so you work > directly towards central. Then you switch back to your procured mirror and > Maven now prevents you from using the artifact that doesn't exist in the > procured mirror. > I'd say everything works as intended then. Maven stops you from using an > artifact that you shouldn't be using according to your configuration. If > you would like to use that artifact, you should be working towards central > directly or your mirror should provide it. > Do you see my point? > > /Anders > > On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org> > wrote: > > > Anders, I have a question for your clarification. I think you're saying > > that because some repositories aren't in best condition, this is a way to > > make sure the intended artifact of the intended repository is downloaded? > > Okay. If that's the case, that sounds like a really weird edge case that > > shouldn't figure into normal use. If I ever encountered such a problem, a > > developer should rely on dependency:purge-local-repository to trash the > > bad > > download. > > > > So is there any room for a Maven enhancement here? I am still not > convinced > > the current behavior is sensible as a default. I really want to allow my > > repositories, with local artifacts pre-cached in my local repository, to > go > > offline without causing a build panic. What are anyone's thoughts on here > > about how Maven could adopt behavior like I want? I could probably write > a > > patch but I'd like a "meeting of the minds" to turn this idea from good > to > > better. > > > > On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> > wrote: > > > > > IIRC this change was introduced as an artifact sometimes differ between > > > repositories. They shouldn't do, but some repos aren't handled > correctly. > > > So if the repo id changes compared to the one stored for a locally > cached > > > artifact, Maven tries to download it again. > > > > > > /Anders > > > > > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org> > > > wrote: > > > > > > > I think you're right. However, I am still curious why Maven is acting > > > like > > > > it does -- in terms of requirements. Maven already has the artifact > > > > locally. There's not a reason (and never a reason?) for it to ever be > > > > retrieved again, right? > > > > > > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> > > wrote: > > > > > > > > > What I think you're running into is that Maven keeps track of from > > > which > > > > > repo an artifact in the local repo was downloaded from. When you > > > > > remove/restore the mirror config the repo id most likely changes > > which > > > > > causes Maven to try to download again. > > > > > There should be a filed named _remote.repositories next to every > > > artifact > > > > > in the loca lrepo where you can find this info. > > > > > > > > > > IIRC this was a change between Maven 2 and Maven 3, or a change > that > > > > > happened very early in the life of Maven 3. Before that Maven > didn't > > > keep > > > > > track of from where an artifact was downloaded. > > > > > > > > > > /Anders > > > > > > > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict < > pbened...@apache.org> > > > > > wrote: > > > > > > > > > > > My Maven version is 3.3.9. For my typical use case, my > settings.xml > > > > has a > > > > > > <mirror> of "central" that provides a procured subset of > artifacts. > > > It > > > > > > contains nearly everything I might need to do a desktop build. > > > However, > > > > > > sometimes I need to connect to the real "central" directly to try > > and > > > > > test > > > > > > an experimental artifact; therefore I temporarily wipe out my > > > <mirror>, > > > > > let > > > > > > Maven resolve the artifact and place it in my local repository, > > and I > > > > can > > > > > > test accordingly. > > > > > > > > > > > > Now this is where my trouble begins. After restoring my <mirror>, > > > Maven > > > > > > complains: "Failure to find xxx:yyy:1.0.0 .... was cached in > local > > > > > > repository, resolution will not be reattempted until...". > > > > > > > > > > > > This is very confusing to me. The artifact version is NOT a > > snapshot. > > > > > Yes, > > > > > > I am online, but why does Maven need to verify the artifact in > the > > > > remote > > > > > > repository given it already resides in my local repository? Since > > > > > > non-snapshots can never be re-updated, I don't see a need for > Maven > > > to > > > > > make > > > > > > a remote connection. It seems unnecessary. > > > > > > > > > > > > Perhaps I am misunderstanding a requirement of Maven. I was > really > > > > > hoping I > > > > > > could be disconnected from the artifact's remote repository, but > > > > > evidently > > > > > > not. Why is Maven acting this way? > > > > > > > > > > > > Thank you! > > > > > > > > > > > > Cheers, > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Cheers, > > > > Paul > > > > > > > > > > > > > > > -- > > Cheers, > > Paul > > > -- Cheers, Paul
