Hi, please check what You have in .m2/repository/org/dom4j/dom4j/2.1.3 in file _remote.repositories There will be references to the repo from where this artifact has been downloaded.
BR Sylwester pon., 6 lis 2023 o 16:57 Tamás Cservenák <ta...@cservenak.net> napisał(a): > 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 > > > > > > > > > > > > > >
