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 <[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
>
-- 

Ádám Sándor

Senior Engineer / Consultant

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

0680126174

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

Reply via email to