Does Jbundler support authentication to private repositories?

[chriskilding]

You can specify a custom repository easily enough with the 'repository "https://somemavenrepo.com" line, but there's nothing in the documentation saying whether this supports authenticated requests using a standard Maven username/password. Can this be done in the Jarfile itself, perhaps similar to the way a build.gradle file has a credentials block in its repository definition:

repositories {
  maven {
    credentials {        
      username [usr]
      password [pwd]
    }
    url "https://somemavenrepo.com/libs-releases-local"
  }
  jcenter()
}

Alternatively does Jbundler obey the authentication definition in settings.xml when downloading artefacts from a URL that matches one in the settings.xml?

Given that the most common reason for hosting your own Maven repo is (probably) to host commercial private JAR artefacts protected by authentication, this seems a bit of an oversight.

[mkristian]

jbundler just uses maven under the hood by translating the Jarfile into a pom.xml so everything which works with maven regarding the settings.xml does work with jbundler.

yes, documentation is missing here:

the repository takes 2 arguments: repository 'private-repo', "https://somemavenrepo.com" which produces following xml:

    <repository>
      <id>private-repo</id>
      <name>private-repo</name>
      <url>https://somemavenrepo.com</url>
    </repository>

I think the <id>private-repo</id> is the link to the settings.xml of yours to pick the right server with authentication.

adding it into the Jarfile itself is quite a tasks since then the next request will be to "extract" those credentials into an external files and/or encrypt them: maven solved these issues already.

let me know if there is still a problem.

[chriskilding]

Ahhh, that's the magic for making it work. So the first arg to 'repository' is actually the Maven ID for a server in the settings.xml <servers> definition block?

In the docs (possibly buried in the wiki somewhere) it said that (originally) this argument was only for giving the repo a name for debugging purposes, and it did not actively affect the way Maven works.

[mkristian]

yes, you are right the wiki is wrong - it is more then just debug help ;)

I will keep this issue open, since I am planning to expose all those other maven features to the Jarfile DSL as well, like checksum-policy and update-policy

then I just need to remember to find all those wiki parts and update them respectively