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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > > 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
