jbang: Dependency resolving error with custom maven repo, multiple runs and a "--deps" declaration

Describe the bug Calling jbang is failing.

The context:

We run ./jbang info tools
We have a custom company maven repo
We use RELEASE as version definition (to get the latest release)

I think the issue depends of the state of the local maven repo (working on this to be sure)

To Reproduce

The script myJangScript has an custom company repo (which aggregates a maven-central mirror and a company maven repo). Something like:

//REPOS acme=https://maven.acme.local/maven

We would like to use the latest version of company-lib

Therefore we are passing --deps company.group.id:company-lib:RELEASE.

In some situations (that I am trying to reproduce now), we have this error:

+ ./jbang info tools --verbose --deps company.group.id:company-lib:RELEASE myJangScript
 Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [jbang] jbang version 0.91.0
 [jbang] System Java version detected as 8
 [jbang] System Java version matches requested version 8
 [jbang] Resolving dependencies...
 [jbang] company.group.id:company-lib:jar:RELEASE
 [jbang] [ERROR] Could not resolve dependencies from mavencentral=https://repo1.maven.org/maven2/
 Unable to collect/resolve dependency tree for a resolution due to: Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE, caused by: Could not find metadata company.group.id:company-lib/maven-metadata.xml in local (/var/lib/jenkins/.m2/repository)
   Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE
 dev.jbang.cli.ExitException: Could not resolve dependencies from mavencentral=https://repo1.maven.org/maven2/
 Unable to collect/resolve dependency tree for a resolution due to: Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE, caused by: Could not find metadata company.group.id:company-lib/maven-metadata.xml in local (/var/lib/jenkins/.m2/repository)
   Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE
 	at dev.jbang.dependencies.DependencyUtil.resolveDependenciesViaAether(DependencyUtil.java:254)
 	at dev.jbang.dependencies.DependencyUtil.resolveDependencies(DependencyUtil.java:122)
 	at dev.jbang.dependencies.DependencyUtil.resolveDependencies(DependencyUtil.java:71)
 	at dev.jbang.dependencies.DependencyResolver.resolve(DependencyResolver.java:67)
 	at dev.jbang.source.RunContext.resolveClassPath(RunContext.java:354)
 	at dev.jbang.cli.BaseInfoCommand$ScriptInfo.<init>(Info.java:95)
 	at dev.jbang.cli.BaseInfoCommand.getInfo(Info.java:163)
 	at dev.jbang.cli.Tools.doCall(Info.java:186)
 	at dev.jbang.cli.BaseCommand.call(BaseCommand.java:93)
 	at dev.jbang.cli.BaseCommand.call(BaseCommand.java:15)
 	at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
 	at picocli.CommandLine.access$1300(CommandLine.java:145)
 	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2352)
 	at picocli.CommandLine$RunLast.handle(CommandLine.java:2346)
 	at dev.jbang.cli.JBang$3.handle(JBang.java:145)
 	at dev.jbang.cli.JBang$3.handle(JBang.java:140)
 	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
 	at picocli.CommandLine.execute(CommandLine.java:2078)
 	at dev.jbang.Main.main(Main.java:14)
 Caused by: org.jboss.shrinkwrap.resolver.api.NoResolvedResultException: Unable to collect/resolve dependency tree for a resolution due to: Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE, caused by: Could not find metadata company.group.id:company-lib/maven-metadata.xml in local (/var/lib/jenkins/.m2/repository)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.wrapException(MavenWorkingSessionImpl.java:503)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:242)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:70)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:52)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:39)
 	at dev.jbang.dependencies.DependencyUtil.resolveDependenciesViaAether(DependencyUtil.java:232)
 	... 18 more
 Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE
 	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:353)
 	at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.resolveDependencies(MavenRepositorySystem.java:121)
 	at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:239)
 	... 22 more
 Caused by: org.eclipse.aether.collection.DependencyCollectionException: Failed to collect dependencies at company.group.id:company-lib:jar:RELEASE
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:291)
 	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:309)
 	... 24 more
 Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for company.group.id:company-lib:jar:RELEASE
 	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:218)
 	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor(DefaultDependencyCollector.java:541)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult(DefaultDependencyCollector.java:524)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:412)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:365)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process(DefaultDependencyCollector.java:352)
 	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:254)
 	... 25 more
 Caused by: org.eclipse.aether.resolution.VersionResolutionException: Failed to resolve version for company.group.id:company-lib:jar:RELEASE: Could not find metadata company.group.id:company-lib/maven-metadata.xml in local (/var/lib/jenkins/.m2/repository)
 	at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:276)
 	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:204)
 	... 32 more
 Caused by: org.eclipse.aether.transfer.MetadataNotFoundException: Could not find metadata company.group.id:company-lib/maven-metadata.xml in local (/var/lib/jenkins/.m2/repository)
 	at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:220)
 	at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:181)
 	at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:213)
 	... 33 more
 [jbang] If you believe this a bug in jbang, open an issue at https://github.com/jbangdev/jbang/issues

Expected behavior The call works, I will post a example where it works (other Jenkins worker where the local maven repo is not the same)

JBang version 0.91.0

Additional context

First wired thing, this looks really wrong:

[ERROR] Could not resolve dependencies from mavencentral=https://repo1.maven.org/maven2/

For me jbang should use the repo defined in the source.

Is it different if I run ./jbang run vs ./jbang info tools

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 21 (21 by maintainers)

Commits related to this issue

fix: fixed problem `--deps` and `//REPOS` If the code had `//REPOS` tags and it would get run with `--deps` on the command line then those deps would not get resolved against the repostories mentione... — committed to quintesse/jbang by quintesse 2 years ago
fix: fixed problem `--deps` and `//REPOS` If the code had `//REPOS` tags and it would get run with `--deps` on the command line then those deps would not get resolved against the repostories mentione... — committed to quintesse/jbang by quintesse 2 years ago
fix: fixed problem `--deps` and `//REPOS` (#1296) If the code had `//REPOS` tags and it would get run with `--deps` on the command line then those deps would not get resolved against the repostorie... — committed to jbangdev/jbang by quintesse 2 years ago

Most upvoted comments

Similar issue solved with the same PR https://github.com/jbangdev/jbang/pull/1296

log.java file:

///usr/bin/env jbang "$0" "$@" ; exit $?

import static java.lang.System.out;

import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;

import java.util.Arrays;

class log {

    static final Logger logger = Logger.getLogger(log.class);

    public static void main(String[] args) {
        BasicConfigurator.configure();
        logger.info("Welcome to jbang");

        Arrays.asList(args).forEach(arg -> logger.warn("arg: " + arg));
        logger.info("Hello from Java!");
    }
}

Then jbang --verbose --deps log4j:log4j:1.2.17 log.java a

[jbang] jbang version 0.91.0
[jbang] System Java version detected as 8
[jbang] No build required. Reusing jar from /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar
[jbang] System Java version matches requested version 8
[jbang] run: /__user_home__/.sdkman/candidates/java/current/bin/java -classpath /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar:/__user_home__/tmp/jbang-tmp/localrepo/log4j/log4j/1.2.17/log4j-1.2.17.jar log a

Run with an other dep: jbang --verbose --deps ch.qos.reload4j:reload4j:1.2.19 log.java a

[jbang] jbang version 0.91.0
[jbang] System Java version detected as 8
[jbang] No build required. Reusing jar from /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar
[jbang] System Java version matches requested version 8
[jbang] run: /__user_home__/.sdkman/candidates/java/current/bin/java -classpath /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar:/__user_home__/tmp/jbang-tmp/localrepo/ch/qos/reload4j/reload4j/1.2.19/reload4j-1.2.19.jar:/__user_home__/tmp/jbang-tmp/localrepo/log4j/log4j/1.2.17/log4j-1.2.17.jar log a

in the second run log4j-1.2.17.jar should not be present. It is just present because of a wrong caching.

Running with –fresh is helping

jbang --fresh --verbose --deps ch.qos.reload4j:reload4j:1.2.19 log.java a

[jbang] jbang version 0.91.0
[jbang] Building as fresh build explicitly requested.
[jbang] System Java version detected as 8
[jbang] System Java version matches requested version 8
[jbang] Resolving dependencies...
[jbang] ch.qos.reload4j:reload4j:jar:1.2.19
Done
[jbang] Dependencies resolved
[jbang] Building jar...
[jbang] compile: /__user_home__/.sdkman/candidates/java/current/bin/javac -classpath /__user_home__/tmp/jbang-tmp/localrepo/ch/qos/reload4j/reload4j/1.2.19/reload4j-1.2.19.jar -d /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar.tmp /__user_home__/.jbang/cache/scripts/21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124/log.java
[jbang] Deleting folder /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar.tmp
[jbang] Resolving dependencies...
[jbang] ch.qos.reload4j:reload4j:jar:1.2.19
Done
[jbang] Dependencies resolved
[jbang] System Java version matches requested version 8
[jbang] run: /__user_home__/.sdkman/candidates/java/current/bin/java -classpath /__user_home__/.jbang/cache/jars/log.java.21794993b5d310604295a249e06db2d98c79086d4af1939af440accbfafc9124.jar:/__user_home__/tmp/jbang-tmp/localrepo/ch/qos/reload4j/reload4j/1.2.19/reload4j-1.2.19.jar log a

Or run with the version from branch quintesse:fix_1292

jmini on Mar 16, 2022

Aha, I actually forgot about this until, trying to find a more limited example, I tried to use build instead of run and that shows:

$ jbang build myJangScript.java 
[jbang] Building jar...
$ jbang --verbose build --deps org.example:dummy:1 myJangScript.java
[jbang] jbang version 0.91.0
[jbang] System Java version detected as 11
[jbang] No build required. Reusing jar from /home/tschotan/.jbang/cache/jars/myJangScript.java.395e890a7f4ef908c924d4c17b643e753251f6db3516b25ca8da341fe0ebd4c0.jar

So in the second case no build is being performed because --deps on the command line are considered “runtime” dependencies (they’ll be added to the classpath but they won’t be recorded as being part of the application’s dependencies).

I’m guessing the problem is that because of this JBang is not even looking at the code and therefore doesn’t take into account the //REPOS tag. And that’s also why clearing the cache or using --fresh does work because it forces JBang to rebuild which forces it to pick up on the //REPOS tag.

(Leaving all this information here mostly for my own recollection, don’t worry if you don’t get all of it)

quintesse on Mar 11, 2022