```* Where: Precompiled script plugin '/home/xeno/...
# community-support
c
Copy code
* Where:
Precompiled script plugin '/home/xeno/IdeaProjects/gradle-convention/buildSrc/src/main/kotlin/our.javalibrary.gradle.kts' line: 1

* What went wrong:
An exception occurred applying plugin request [id: 'com.xenoterracide.gradle.convention.publish']
> Failed to apply plugin 'com.xenoterracide.gradle.convention.publish'.
   > Cannot query the value of extension 'repositoryHost' property 'namespace' because it has no value available.
Copy code
public interface RepositoryHostExtension {
  Property<String> getNamespace();

  default URI cloneUrl() {
    return this.getHost().get().resolve(String.join("/", getNamespace().get(), getName().get(), getExtension().get()));
  }
so, how can I apply the plugin to set up the extension so the values go into the plugin
Copy code
pom.scm(scm -> {
            scm.getConnection().set(repo.cloneUrl().toString());
entire plugin https://github.com/xenoterracide/gradle-convention/blob/main/module/publish/src/ma[…]/com/xenoterracide/gradle/convention/publish/PublishPlugin.java
v
cloneUrl()
should probably not eagerly evaluate those properties, but
zip
them together and return a
Provider<URI>
, so that it can be wired and evaluated lazy
c
I considered making them a provider, but how should I get one in the extension? also, never used zip
v
how should I get one in the extension
I don't understand the question
also, never used zip
providerOne.zip(providerTwo) { valueOfProvider1, valueOfProvider2 -> combinedValue }
c
I don't have a provider for
packageUrl
well, at least not a base one...
and that one is being used by something that won't take a provider
v
I don't know what
packageUrl
is, first time you mention it
c
Copy code
default URI packageUrl() {
    return URI.create("<https://maven.pkg.github.com>").resolve(
      String.join("/", this.getNamespace().get(), this.getName().get())
    );
  }
I suppose I could make it weird, I assume you're suggesting I use the properties as providers
like getHost().zip
v
I assume you're suggesting I use the properties as providers
Property
is a subclass of
Provider
, so yes, that is how it is supposed to be used. You wire properties and providers together combine them and so on and optimally only ever at execution time use
get()
. Whenever you use
get()
at configuration time you at least introduce a race condition.
c
well, I'm using it like this
Copy code
var publishing = project.getExtensions().getByType(PublishingExtension.class);
    publishing.repositories(pubRepo -> {
      pubRepo.maven(maven -> {
        maven.setName("gh");
        maven.setUrl(repo.packageUrl());
        maven.credentials(PasswordCredentials.class);
      });
    });
maybe there's no hope for setting the repo url that way?
unless the
setUrl(Object
can also take a provider
wait, zip mutates the 2nd argument?
oh, one of those weird EP isms where the var rule gets flagged because something else did
I need to find a minimal reproducer for that
at least this time it wasn't nullable stuff
I guess maybe it does, would be nice if it was truly statically typed instead of taking
Object
Tomorrow, let the dog food ing commence!
Also, majority death to kotlin plugins
v
unless the
setUrl(Object
can also take a provider
iirc it is toString-lazy, so set it to an object that evaluates the value once
toString()
is called the first time
wait, zip mutates the 2nd argument?
No,
Provider
cannot be mutated.
c
No zip doesn't mutate the second argument. Error-prone just got stupid. Now I'm going to have to close that bug that was sitting in standby since now I've seen that behavior out of something other than nullaway. I don't know why but occasionally if he gets stupid and decides to report a bunch of things as var (mutable variable must be annotated) when something else is failing. In this case the real cause of the problem was I had an unused variable.
Yeah I haven't figured out if it actually takes a provider yet. If it doesn't is there any actual solution? Or am I just going to have to provide that one directly?
Configuration didn't blow up this last time but I don't know that that means anything since that URL probably didn't have anything done with it yet
Since it's the publish to URL
v
Looks to me as if
setUrl
can properly handle
Provider
, yes. At least from quickly clicking on the method and looking at the code
c
Yeah from the javadock it wasn't clear
To me because it's like it uses the same thing as blah blah blah and going through the blah blah blah it still didn't say whether or not it accepts providers
v
Sourcecode is always the best and most up-to-date documentation. 😄 But well, the JavaDoc says it is evaluated like
Project.uri(Object)
, which says it is evaluated like
Project.file(Object)
but accepting URLs with other schemes than
file:
, which says that
Provider
is supported, so, ... 🙂
c
How does saying that accepting other schemes than file... Mean that provider is accepted
v
The last "which" meant the JavaDoc of
Project.file(Object)
c
Right, well I can't look at it again right now. I've got a cat on my lap. Either way it sounds like it works. It'd be nice if the method was more statically typed though. Object being the weakest of all types
v
Indeed. That's most probably one of the historically grown signatures from Groovy-only time. Maybe they improve on that with the `Property`ization in Gradle 9, I don't know.
c
Well at least it means I won't have to reduplicate my code
👌 1