https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
I think you need a provider.getEnvironment
g
googling
c
g
Cannot query the value of this provider because it has no value available.
c
g
same
am I supposed to do some ceremony somewhere or can I call it randomly wherever I want?
my guess is that the Gradle context hasn't it set..
c
yeah, sadly that's probably going to be I can't help further... but you might want to show more of your code as to where you're doing what I'm doing and maybe your terminal
g
but on terminal I go get some output
c
basically, show me the code 😉
but this is the lazy/configuration cache safe way
although I'm not certain if I always use the API right. I blame @Vampire if I get it wrong, and he's probably of more help but will not love the summoning
g
I need it to set it here
in order to have it in the context of the source code later on (I'm gonna instantiate a new vm and need to check some places)
will not love the summoning
Let's see 😄
ps: note that in the code is empty
that's why I'm trying to set it from Gradle
c
hmm... you're trying to set the property for the native execution? why are you getting it from 
java.home
?
Copy code
environment("JAVA_HOME", providers.environmentVariable("JAVA_HOME"))
maybe?
that's me slack coding, I don't know for sure that'll take a provider
g
although I get a different output.. on terminal I get
elect@5800x:~/IdeaProjects/java-launcher$ echo $JAVA_HOME
/usr/lib/jvm/java-11-openjdk-amd64
while 
"java.home"
is 
/home/elect/.jdks/openjdk-19.0.1
, which is the Idea jdk I guess
I'll try
c
Can you use a Java ToolChain here to avoid the low-level launching of a specific JVM?
c
I mean, just because you have JAVA_HOME doesn't mean that java.home property is set
or vice versa
g
Can you use a Java ToolChain here to avoid the low-level launching of a specific JVM?
Sure, I can
environment("JAVA_HOME", providers.environmentVariable("JAVA_HOME"))
"echo \$JAVA_HOME".execute()
returns
valueof(EnvironmentVariableValueSource)
c
providers.environmentVariable("JAVA_HOME").get()
🫠 1
g
right, however still
Cannot query the value of this provider because it has no value available.
c
doesn't 
.get
make it eager or something in a way you might not want? also it sounds like there's 2 sources so maybe you need a 
getOrElse(
...
like try JAVA_HOME then try java.home
and if neither value is set...
g
Can you use a Java ToolChain here to avoid the low-level launching of a specific JVM?
I mean, between using a specific jdk and using whatever jdk Idea is running, I don't see any differences for my purposes, though
like try JAVA_HOME then try java.home
same
Cannot query the value of this provider because it has no value available.
c
in "recent" versions you can tell gradle which version of java specifically to use
g
yeah I know, but I need just one 
libjvm
, I don't think I care which one
so, as long as 
java.home
returns me a valid, I guess I might be happy..
c
and that task doesn't work if you call gradle on the cli (not through intellij)
g
uh, right
c
so 
JAVA_HOME="..." ./gradlew build
with 
environment("JAVA_HOME", providers.environmentVariable("JAVA_HOME").get())
is throwing an NPE? or...
g
this is funny, on terminal
Copy code
./gradlew runDebungExecutableNative
returns my 
JAVA_HOME
/usr/lib/jvm/java-11-openjdk-amd64
c
intellij does not get your terminal environment settings
so how are you running this?
g
but it was actually a very useful insight, Caleb, coz where in the end, I won't be running this via Idea
c
and java doesn't do environment to property conversions (spring boot for example has some magic that will)
g
thanks for helping me out, Caleb and Chris
👍 2
m
Copy code
/**
 * We have one environment where gradle choses a non-jdk java,
 *  and another where JAVA_HOME is not set.  This is a trial
 *  by fire approach.
 */
ext {
    if (System.getenv('JAVA_HOME') == null) {
        cJDK = System.properties['java.home']
    } else {
        cJDK = System.getenv('JAVA_HOME')
    }
}
c
I would not use 
System.
for this in gradle anymore, use the providers (although this looks like groovy, not sure how providers work there)
👍 1
v
I'm neither sure why I was summoned, nor really got what the content of this discussion is. But using 
System.
is fine, especially if you need the value eagerly and not as provider. Especially if it is an environment variable which are more or less read-only anyway.
👍 1
And using 
System.
should also be perfectly CC-compatible and -safe. That you needed to use the providers for CC was just an intermediate situation while it was still incubating.
👍 2
And if it is set on commandline, you should also be able to get it in the build script, if you actually invoke Gradle from that command line. From tests or other worker daemon it would be different though. Or if you invoke from IDE and there have not set the environment variable too. The question is, why you would want to get it actually.
g
we are porting a java launcher from C to Kotlin MPP, more here and here Long short story, we need libjvm and we start looking into 
usr/lib/jvm/default-java
, if that doesn't exist, we fallback to 
JAVA_HOME
, and so on..
v
Well, as I said, if the environment variable is available in a commandline and you start Gradle from that commandline, it should also be available in the build script. But maybe you should instead use the JVM toolchains feature to get a JVM installation that suits your needs?
g
Well, as I said, if the environment variable is available in a commandline and you start Gradle from that commandline, it should also be available in the build script.
yep, that's what I discovered
I guess any jdk (1.8+) we find may be useful for our purpose
v
Then why don't you just always use the Java Gradle was started with?
The system property 
*java*.*home
should always give you that.*
g
because it's a Kotlin MPP project and after packaging it, there won't be any Gradle
v
Oh, I see, but you seaid you want to get it in your build script, not at execution time. Because if you need it at execution time, talking about how to get it in build script and using the environment variable providers and so on all does make little sense. And also then it would not really be a Gradle topic.
g
implementing in Gradle was the fastest way to get a prototype for testing and then, step by step, moving the logic outside
v
Aha, so do you still need something I was summoned for, or are you happy now? 🙂
g
😄 for the moment I'm happy/busy
👌 1
c
so why did you tell me I needed to use providers instead of System? @Vampire (99% chance of it being true it was you who said stop doing that)
v
When did I say that an in which context?
As I said, long ago in the beginnings of CC this was true so that they are recognized as CC inputs properly. But since quite some time the whole buildscript classpath is automatically instrumented to also recognize normal usage of 
System....
or ways to execute processes and so on as CC input. Otherwise you could for example not as easily use 3rd party libs doing such actions without finding out what exactly they do and what needs to be declared as CC input.
👍 2
c
So they are legacy? Is it going to end up being like for configuration where it's deprecated ?
v
They are not legacy. They are still useful if you for example want to fill something taking a provider with one of those, or if you want to delay evaluation of a system property which could change until then, or if you want all with a certain prefix in a way that not each and every existing ends up as CC input. But to get a single one that you immediately need for something, it is no longer necessary to use them for it to be considered as CC input.
👍 2
3 Views
Open in Slack
PreviousNext
Powered by