[Feature request] An option that read maven central passord from local.properties
See original GitHub issueI know it is recommended to set them in ~/.gradle/gradle.properties.
But if I have more than one maven central account, things get troublesome. So I prefer put them in local.properties
to the main properties file.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Where to put Gradle configuration (i.e. credentials) that should ...
I advise pass project properties as follows authentication(userName: project.properties.mavenUser, password: project.properties.mavenPassword) This will not ...
Read more >Password Encryption - Apache Maven
Maven supports server password encryption. The main use case, addressed by this solution is: multiple users share the same build machine (server, CI...
Read more >Declaring repositories - Gradle User Manual
Repositories with custom URLs can be specified as Maven or Ivy repositories by calling the corresponding methods available on the RepositoryHandler API. Gradle ......
Read more >Publishing Android libraries to MavenCentral in 2021
As we eluded to earlier, artifacts published on MavenCentral have to be signed by their publishers. You'll need a GPG key for this....
Read more >Maven packages in the Package Registry - GitLab Docs
Request forwarding to Maven Central. By default this feature is not available for self-managed. To make it available, ask an administrator to ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
After some digging I finally figured out how this can be done.
In your main build script you’ll want to do something like the following:
The above will add all the properties from local.properties to the root project which can then be retrieved using project.findProperty(‘<property>’) from other projects. This alone isn’t sufficient however as the mavenCentralUsername and mavenCentralPassword don’t appear to be detected by the plugin when applying this way. So you’d also need to do the following wherever you’re configuring the publishing plugins.
I found that the first part worked well for setting variables for the signing plugin, and it will likely work for others as well. Unfortunately I haven’t found a way to set mavenCentralUsername/mavenCentralPassword dynamically without setting sonatypeHost to null and then defining the maven repository details in the publishing plugins repositories.
Here are some findings that explain why mavenCentralUsername/Password can’t be read from a local properties file even though the properties exist.
This plugin relies on Gradle’s built-in PasswordCredentials factory as seen below:
https://github.com/vanniktech/gradle-maven-publish-plugin/blob/4b8e7815bff3cf9a0a6b54db13d37db52bc0c29f/src/main/kotlin/com/vanniktech/maven/publish/MavenPublishBaseExtension.kt#L70-L75
The internal implementations the factory uses creates an instance of DefaultGradleProperties which, once loaded, will never be mutated. As such, setting ext properties at runtime won’t modify this internally managed list of properties. So as expected, the properties set with the method in my first code snippet won’t work due to the fact that the properties are not being resolved the same way they are when calling `project.findProperty(‘<key>’).
So our only option at the moment is to apply the second code snippet so that we set the credentials from within our own scripts. I think a way to resolve this would be to maintain a custom implementation of PasswordCredentials and instantiating it with the properties found via
project.findProperty
.@martinbonnin Thanks. But, environment variables seem to be more suitable for CI. It is not applicable in ordinary development.
Of course, publishing to maven is not a very frequent operation, so thank you for your tip.