Hi Tamas et al,
When I add the repository to the settings.xml of my main computer, which actually will never connect to the repository,
it works. I can then do the offline build successfully.
Its a bit strange, that I have to add a repo to the settings.xml even though it will never be accessed, because on that
maschine I will alway make online offline builds. But I understand the logic behind it of having all neccessary build
information together. If anyone cares, the error message could be improved.
thanks for the help,
Arno
On 06.11.23 16:56, Tamás Cservenák wrote:
Howdy,
Well, let me step back for a moment:
Maven2 did ignore "origin" and it caused various problems that were very
hard to diagnose.
Hence, Maven3 (from start, or almost, but very early) did implement the
"enhanced" local repository, that does track origin.
In short, these kinds of errors means that your build depends on something
not described in build (so side effect).
Best way to diagnose these: nuke local repository (as it should be
considered transient anyway), and a "good build" will just get whatever it
needs.
Otherwise, the build will fail as well, but with a different error:
"artifact X not found".
With use of repository groups (virtual repo) this became more and more
apparent: Imagine this, you have two groups:
group-a (consisting of central, remote-repo-a)
group-b (consisting of central, remote-repo-b)
Here, if you start a build w/ settings "by the book" (having mirrorOf
group-a) and empty local repo, it will populate your local repo and all
cached artifacts will have the origin = "group-a".
Then, if you start another build w/ settings "by the book" using group-b,
Maven will go and recheck all, as "group-a" origin is != as "group-b"
origin (so yes, all the central artifacts as well, everything).
Hence, in these scenarios is best to differentiate local repositories as
well (just like you differentiate groups).
Also, if no origin check, an artifact coming from remote-repo-a, that is
totally out of sight in build consuming group-b could be picked up, causing
strange, and very hard to diagnose problems (it fails here but passes
there? It is a build that depends on the environment, and how is the used
local repo populated).
So, ideally in these cases just use _other_ local repository, ideally 1:1,
each build consuming given group should have "own" local repository as well.
I cannot emphasize enough, how in these cases usually "nuking local repo"
just makes the issues pop out, and render builds fail, and it is a clear
indicator that the build has issues that need to be fixed.
Again, you can "trick" Maven to use these "unavailable" artifacts, but it
is in your own interest to fix the actual build issues you have.
On Mon, Nov 6, 2023 at 4:31 PM Francois Marot <francois.ma...@gmail.com>
wrote:
> Hello Arno and Tamas
>
> and thank you for the detailed and very interesting explanation.
> One question arises though: is there any way to make Maven ignore the
> origin ?
>
> Have a good day
> François
>
>
> Le lun. 6 nov. 2023 à 13:20, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > The Maven local repository contains two kinds of artifacts lumped
> together:
> > - cached ones from remote
> > - locally built and installed
> >
> > This message matters the cached ones: "present but unavailable" means
> > following:
> > - file IS present (so it was cached)
> > - but is unavailable, as it was cached as part of some OTHER remote
> > repository than that exists in current execution
> >
> > Maven3 uses this implementation of local repository
> >
> >
>
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/internal/impl/EnhancedLocalRepositoryManagerFactory.html
> >
> > And check out the javadoc it: it tracks the "origin" (basically remote
> > repository ID) of cached artifacts, and "emulates" physically separated
> > caches (same can be achieved "for real" with split local repository).
> >
> > In short: the repository ID that was stored as artifact origin is NOT
> > available in your subsequent build, hence, Maven3 does not use it (is
> > unavailable, but present physically in cache/local repository).
> >
> > HTH
> > T
> >
> > On Mon, Nov 6, 2023 at 1:10 PM Arno Schatz <a...@xerai.biz> wrote:
> >
> > > Hi,
> > >
> > > I am trying to use the offline mode (mvn -o clean install) and getting
> > the
> > > error message
> > > "The following artifacts could not be resolved:
> org.dom4j:dom4j:jar:2.1.3
> > > (present, but unavailable)"
> > > for very many dependencies.
> > >
> > > My main computer and a VM share the same file system. The VM is
> connected
> > > to the company's repository (artefactory)
> > > through VPN. On the VM, I checkout the project and successfully build
> it
> > > and successfully ran "mvn dependency:go-offline".
> > >
> > > The I switched to my main computer and tried "mvn -o clean install" but
> > it
> > > failed with the above error message. I also
> > > tried to set
> > > <offline>true</offline>
> > > in settings.xml in my main computer but that didnt change anything.
> > > What does the "(present, but unavailable)" in the error message mean?
> > >
> > > thanks,
> > > Arno
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
