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