Question regarding Maven's local repository use

[Paul Benedict <pb...@apache.org>]

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

Re: Question regarding Maven's local repository use

[Adam Sandor <ad...@container-solutions.com>]

The issue here is that the build always runs in a brand new container so at
the start no artifacts are available locally. All the artifacts that are
fetched by the dependency:go-offline task will be cached in a Docker image
layer and reused in later builds if the pom.xml doesn’t change. This would
be great if the dependency:go-offline task actually downloaded all the
dependencies. Because it doesn’t do so every time you change your code a
lot of dependencies will get downloaded, even if not all.

On Mon, Feb 5, 2018 at 5:05 PM Paul Benedict <pb...@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 <an...@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 <pb...@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
>
-- 

Ádám Sándor

Senior Engineer / Consultant

Container Solutions <http://container-solutions.com/>

0680126174

<https://twitter.com/adamsand0r> <https://www.linkedin.com/in/adamsandor/>

Re: Question regarding Maven's local repository use

[Paul Benedict <pb...@apache.org>]

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 <an...@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 <pb...@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 <an...@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 <pb...@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 <an...@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 <
> pbenedict@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

Re: Question regarding Maven's local repository use

[Anders Hammar <an...@hammar.net>]

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 <pb...@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 <an...@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 <pb...@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 <an...@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 <pb...@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
>

Re: Question regarding Maven's local repository use

[Paul Benedict <pb...@apache.org>]

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 <an...@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 <pb...@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 <an...@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 <pb...@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

Re: Question regarding Maven's local repository use

[Anders Hammar <an...@hammar.net>]

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 <pb...@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 <an...@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 <pb...@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
>

Re: Question regarding Maven's local repository use

[Paul Benedict <pb...@apache.org>]

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 <an...@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 <pb...@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

Re: Question regarding Maven's local repository use

[Anders Hammar <an...@hammar.net>]

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 <pb...@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
>