Allow mavenlocal repository to be configured

[aalmiray]

Sometimes you want to test out things locally and would like mavenlocal to resolve first.

[maxandersen]

got an example where it does not resolve/use mavenlocal as you expect it to ?

seems to "just work" for me.

[cplerch]

Couldn't find a reference to mavenlocal in the docs, though.

[maxandersen]

What is your expectation here ? Got an example of where it doesn't just work as expected ?

[cplerch]

Well, it simply wont lookup dependencies in the local maven repo ~/.m2 when you try to declare such dependency that only resides there but not in a public repo. E.g. I want a local-only dependency eu.km-works.utils:utils-core:2.0.0

Neither //DEPS eu.km-works.utils:utils-core:2.0.0 nor

@Grapes({ // (3)
		@Grab(group = "eu.km-works.utils", module = "utils-core", version = "2.0.0")
})

works.

Error message is:

[jbang] Resolving dependencies...
[jbang]     Resolving eu.km-works.utils:utils-core:2.0.0...[jbang] Deleting folder C:\Users\cpl\.jbang\cache\jars\SimpleFileIterator.java.2736e9d3010d2905ca13c514a04ad74696f30cdada43f277062a456a12179886
[jbang] [ERROR] Could not resolve dependency
dev.jbang.ExitException: Could not resolve dependency

[cplerch]

Alright, there is some news on this issue: jbang indeed resolves by default dependencies from the local maven repo, but only if the repository resides in its default path ~/.m2/repository. In my case however I have redirected the localMaven repository store to a different path via ~/.m2/settings.xml like so:

<settings>
	<localRepository>C:/_/dev/repos/m2</localRepository>
	<interactiveMode>false></interactiveMode>
</settings>

In this case jbang cannot resolve the dependency from mavenLocal. Perhaps it simply ignores (or misreads) the maven settings file. Can/will this be fixed?

[aalmiray]

Well in my case Maven Local is in the default path and it didn't work either.

[cplerch]

Good to know. In my case (Windows 10 Pro) it did work after I copied the dependency to the default repository path. What's your OS/platform Andreas?

[quintesse]

Just a test, but could you try to run jbang info tools <your_script> and perhaps share its output? Or at least check if the paths it shows are correct?

[quintesse]

Btw @maxandersen just tried it with setting localRepository and it does seems that the dependency resolver doesn't take that setting into account.

[cplerch]

Just a test, but could you try to run jbang info tools <your_script> and perhaps share its output? Or at least check if the paths it shows are correct?

Sure:

C:\_\dev\ws\java-scriptlets\src\kmw\script>jbang info tools SimpleFileIterator.java
{
  "originalResource": "SimpleFileIterator.java",
  "backingResource": "SimpleFileIterator.java",
  "resolvedDependencies": [
    "C:\\Users\\cpl\\.m2\\repository\\eu\\km-works\\utils\\utils-core\\2.0.0\\utils-core-2.0.0.jar",
    "C:\\Users\\cpl\\.m2\\repository\\com\\typesafe\\config\\1.3.2\\config-1.3.2.jar",
    "C:\\Users\\cpl\\.m2\\repository\\com\\google\\guava\\guava\\24.0-jre\\guava-24.0-jre.jar",
    "C:\\Users\\cpl\\.m2\\repository\\com\\google\\code\\findbugs\\jsr305\\1.3.9\\jsr305-1.3.9.jar"
  ]
}

Note: The directory C:\\Users\\cpl\\.m2\\repository did not exist in this location before jbang tried (and failed) to resolve dependencies. For resolution to work (as depicted above) I had to a) create this directory and b) manually copy the only local dependency utils-core-2.0.0.jar here. Only then the other 3 dependencies have been resolved from public repositories automatically by jbang and also been cached in this wrong "repository" location. The later now only reside there but not in my real localMaven repo which lives on another path on a separate disk. Hope that helps.

[maxandersen]

Btw @maxandersen just tried it with setting localRepository and it does seems that the dependency resolver doesn't take that setting into account.

What did you try exactly ?

[maxandersen]

Alright, there is some news on this issue:

jbang indeed resolves by default dependencies from the local maven repo, but only if the repository resides in its default path ~/.m2/repository. In my case however I have redirected the localMaven repository store to a different path via ~/.m2/settings.xml like so:

<settings>

	<localRepository>C:/_/dev/repos/m2</localRepository>

	<interactiveMode>false></interactiveMode>

</settings>

In this case jbang cannot resolve the dependency from mavenLocal. Perhaps it simply ignores (or misreads) the maven settings file. Can/will this be fixed?

Okey, not honoring settings.xml definitely sounds like a bug as it should be reading that anyway for auth settings.

But sounds like we have two bugs: resolution from localrepo and using the right location when it's been customized.

[maxandersen]

C:/_/dev/repos/m2 false>

so i finally could go take a closer look - we currently do NOT read this for local repository info. I've opened #602 to discuss how/if we should fix that.

You can though control it using JBANG_REPO env variable so could you check if you set JBANG_REPO=C:/_/dev/repos/m2 that it works as expected for you?

[maxandersen]

About the core of this issue then you should be able to explicitly do the following today:

//REPOS local=file:///Users/max/.m2/repository

but I reckon what being asked for is something like //REPOS mavenlocal or similar to not have to specify a user bound path.

For that we would need to call .useLegacyLocalRepo(true) on the shrinkwrap resolver.

that should be farily easy. let me make a PR for that - and you can try out if works for you.

[quintesse]

Thing is that I don't know if that's what people would expect. Especially because it would depend on the script author having added the //REPOS mavenlocal line to their scripts. But I think what they expect is that Jbang would respect their global system setting, IMO having a localRepository in the settings.xml should be treated the same as having a JBANG_REPO env var set.

[maxandersen]

That is #602

Here it is about wether you want artifacts in local Repo only to be found.

Running in --offline does that but not offline it won't.

[quintesse]

That is #602

Ah ok :sweat_smile:

[vorburger]

I bumped into this in https://github.com/enola-dev/enola/issues/1040, it appears that something may have changed related to local Maven repo between JBang 0.122.0 and 0.123.0.

[vorburger]

I bumped into this in enola-dev/enola#1040, it appears that something may have changed related to local Maven repo between JBang 0.122.0 and 0.123.0.

That may have been a red herring, it looks that problem is caused by something else (not mavenlocal, which does appear to work) - please ignore this comment.

[maxandersen]

yeah its unrelated imo.

for this issue we know what code to change but I can't think of what usecase it solve - if anyone can show a jbang script that doesn't do as expected without having mavenlocal setup that would be great.