https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
Untitled.sh
v
That you have to call the wrapper task twice to also update the wrapper files is a bit annoying, yes. For that there is for example https://github.com/gradle/gradle/issues/884. And I usually update the version in the file manually and then call the 
wrapper
task once. The distribution URL you should be able to configure in the build script or via argument as far as I remember to not need the 
sed
. But why do you need to update the lock files when upgrading Gradle? Those actions shouldn't be directly related, should they?
c
I haven't seen a way to do the distribution url... this isn't just to update gradle, it's actually to update the locks. when you update gradle itself I've seen it break on locked versions of things... I think it was kotlin related. Very annoying
I don't have an example handy sadly
but it's happened to me, so I started doing it
same reason I delete the locks first, I've seen it happen. Not every time, but some times it does
v
Copy code
tasks.wrapper {
    distributionUrl = ...
}
and / or
Copy code
gw wrapper --gradle-distribution-url ...
👍 1
c
so instead of providing the version I provide the final destination?
Copy code
+ ./gradlew wrapper --write-locks --gradle-version 8.5 --gradle-distribution-url <https://myorg.jfrog.io/artifactory/gradle-distributions/>
Exception in thread "main" java.lang.RuntimeException: Downloaded distribution file /Users/ccushing/.gradle/wrapper/dists/gradle-distributions/1pbmfpj97mcv4jv8t62lgs5qp/gradle-distributions is no valid zip file.
	at org.gradle.wrapper.Install$1.call(SourceFile:26)
	at org.gradle.wrapper.GradleWrapperMain.main(SourceFile:67)
v
Yes, you would directly provide the full URL instead of the version afair. Hopefully with https://github.com/gradle/gradle/issues/17515 in Gradle 9, you could do something like 
distributionUrl = gradleVersion.map { "<https://myorg.jfrog.io/artifactory/gradle-distributions/gradle-$it-bin.zip>" }
in the build script and then again just use 
--gradle-version
c
the better way would be 
distributionUrlBase
turns out if you get the url wrong it breaks gradlew
that alone might be enough reason to prefer the sed patch. Unless they decide to do something like prevent accessing services locally
which one company did to me
v
Maybe worth reporting an issue or feature request, that the wrapper task should for example do a 
HEAD
request before writing it to the file or similar to verify the URL at least return something valid.
c
idk, 2016 on that other bug. I keep feeling like gradle's issue tracker is where bugs go to die, not that they get fixed here either
if you're interested in why I delete lockfiles
another bug that went somewhere to die
v
Well, Gradle folks are a bit short on human resources, so they cannot work on all things in a timely manner unfortunately. 😞
But the welcome pull requests. 😉 🙂
c
I don't do PRs without someone telling me that they would actually accept one. Over time and open source I've had way too many PRs not get pulled in even if the final result looks a lot like the PR that I did. I dislike not getting credit for work that I actually did. I also dislike wasting my time.
Also, to work on any PRs I would actually need someone to help me because I don't actually understand enough
v
Totally understandable. But as someone who gets PRs in almost every release, I can say that they do accept PRs. 🙂 And to be extra sure about the concrete topic, you can first ask in the respective issue about whether a PR for that topic would be accepted. That's even recommended by them, although I practically never do it. 😄 To quote the start of https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md:
Before starting to work on a feature or a bug fix, please open an issue to discuss the use case or bug with us. This can save everyone a lot of time and frustration.
c
you asked for a feature ticket 😉 https://github.com/gradle/gradle/issues/27295
so vote!
also for the other bug
I'm tempted to make a meta bug that is "make my script go away"
❤️ 1
and link all these...
v
Not actually the issue I asked for though. 😄 But yeah, why not. What I recommended was an issue to do a HEAD request to a distribution URL before it is written to the properties file.
Btw. even with 
file:///
or 
ftp://
it would be URLs. URL = Uniform Resource Locator So if the "thing" allows to locate a resource like a file, it is an URL. An URI is a Uniform Resource Identifier These can be things that are also valid for an URL or can just look similar or also look completely different and do not necessarily allow to locate a resource, but just to identify a resource. For example the entity id in a SAML login process typically is an URI. It often is also a valid URL where the respective entity can be accessed, but it does not have to be. 🙂
c
arguably so is the term
so maybe if I read the wikipedia... lol, but anyways. I'm indifferent. I don't really care that protocol is included either, that's not my main goal it just makes paste-ability easier if one gets rid of it. There may be other one's but they aren't really a focus
v
URL class is not deprecated, only the constructors are deprecated. You can use any URL also as URI, so you can first construct an URI and then convert it to URL. Still all I said holds. URI identifies "something", this can be a physically available resource like a downloadable file, but can also be a logical identifier like entity id in SAML. An URL is a special case that is the ones that describe physically available resources.
c
fair
I'm so tired of working around gradle's deficiencies. I'd like to see like a handlful of my issues get closed "successfully" and not marked as duplicate in favor of a later reporter (that's really frustrating) https://github.com/gradle/gradle/issues?q=is%3Aissue+author%3Axenoterracide
I don't think any of the ones that were fixed, were fixed as a result of my report
they just got closed later
which is why when you tell me to open bugs, I'm like "why" and a good number of my open issues aren't in a "patches welcome state" same for the duplicate issues.
gradle is really powerful, and probably the best build tool for java. Honestly though it's kind of a pain in the ass because I'm always working around it. Other languages have build tools that are much easier to work with and I don't feel the need to constantly write plugins or code to fix.
some are verified, just not fixed
if you run 
gradle wrapper
by itself it'll update the distribution url
🤯
my sed expression actually worked, this doesn't 🤦‍♂️
v
Sure, that's one of its tasks, not getting what you mean
c
it's not what I want though
v
You configure it via build script, or as commandline argument, as I showed. Just writing it to the properties file is not helpful as the 
wrapper
task overwrites the file.
c
but I'm not telling it to update the version...
v
No, you are telling it to write the 4 wrapper files
Not giving it an explicit version just means it reuses the same version
c
IIRC kotlin script also adds dependencies on things like kotlin, to locks
when you upgrade
so what I want it to do is add any locks and leave the rest alone
v
Then don't call the 
wrapper
task
c
got a better thing to do to set the locks for kotlin script?
the ones that gradle itself needs
v
I don't use dependency locking, I use concrete versions
c
afaik, there isn't one
v
Actually, as long as you don't lock the 
classpath
configuration of the 
buildscript
block, I wouldn't expect to get something into the lock files due to Kotlin DSL
c
ah yeah, now I know where I've seen it, it's in buildSrc, and I have had to update the locks when updating gradle https://github.com/xenoterracide/ai-wh40k/blob/7b98ab84fece16a046ab3e95099e8d8096f97ebe/buildSrc/gradle.lockfile#L35
but if I'm not updating gradle and I delete my locks I still need to regenerate them
so... yeah, sed patch
yeah, but I want to lock buildscript, so...
do you know of a better way to do that? can I do 
buildSrc:dependencies --write-locks
?
v
If you are on Gradle 8+ I think that should work
c
hmm
looks like it might...
Copy code
❯ ./gradlew buildSrc:dependencies
Calculating task graph as no configuration cache is available for tasks: buildSrc:dependencies
Type-safe project accessors is an incubating feature.
The Daemon will expire after the build after running out of JVM Metaspace.
The project memory settings are likely not configured or are configured to an insufficient value.
The daemon will restart for the next build, which may increase subsequent build times.
These settings can be adjusted by setting 'org.gradle.jvmargs' in 'gradle.properties'.
The currently configured max heap space is '512 MiB' and the configured max metaspace is '384 MiB'.
For more information on how to set these values, please refer to <https://docs.gradle.org/8.4/userguide/build_environment.html#sec:configuring_jvm_memory> in the Gradle documentation.
To disable this warning, set 'org.gradle.daemon.performance.disable-logging=true'.
Daemon will be stopped at the end of the build after running out of JVM Metaspace

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/ccushing/IdeaProjects/ai-wh40k/module/game/build.gradle.kts' line: 14

* What went wrong:
Metaspace

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at <https://help.gradle.org>.
that's a fun error... but running it a second time works...
v
Yeah, well out of memory due to too many loaded classes. Can happen. Second time was new daemon so worked.
Btw. feature request to do the 
HEAD
request is not necessary. The wrapper task already does that if you provide a custom distribution url with 
http
or 
https
, so it should not actually write invalid distribution urls to the properties file unless the 
HEAD
request indeed was successful.
c
idk, it wrote an invalid file for me... I had to reset it a few times
I think the head was successful, but the url was not a zip file
so there was something there, but not a valid gradle zip
and it left gradlew completely broken...
be me, be dumber 😉 and you find interesting ways to break stuff
for security purposes there should probably be a shipped signed sha512 file that is also downloaded and then used to validate the zip. That's not perfect because the live on the same server, but it's better than assuming a HEAD saying a resource exists, that said resource is both valid and untampered with. If validating the sha file is inconvenient due to pgp not being in java, then you could just have the sha file, that'd be good enough
btw, if you want to know how to reproduce that issue, pretty easy https://github.com/gradle/gradle/issues/27310
v
Yeah, as I said, if the HEAD request is successful, it will of course write an invalid URL in there if it points to the wrong thing. But downloading the whole distribution just to verify the URL is correct would mean the 
wrapper
task needs extremely significant more time. And usually you can just revert the changes, or at worst delete the file and regenerate. I guess it is not worth really downloading the wohle file just to verify the URL.
c
right, the problem isn't verifying the url, it's writing the url to the properties file when can break the wrapper. Typo-ing something shouldn't result in a broken wrapper.
you'd need to download it anyways right? just don't flush to the properties file until you know it works
obviously don't download everything unless HEAD works.
v
you'd need to download it anyways right?
No, why?
c
I mean, I can't imagine passing these parameters in a way that I expect a mutation of the properties file where it wouldn't refetch
I'm just fine redownloading it to avoid breaking things if it's going to mutate the wrapper
wrapper.properties
besides, part of what happened here is it obviously downloaded it, and then set that result to be used
v
Not sure what you mean. It does not download anything currently.
c
did you run the code in the ticket?
the "minimal reproducer"
you're saying that doesn't download anything?
also, gradle shouldn't depend on a vcs to fix problems
v
The first call, the 
wrapper
excecution does not download anything, so your description is wrong anyway. It uses a 
HEAD
request as a minimal measure to validate the given URL. The download is happening on the second command that will then try to download and use that distribution and fail. So there is nothing that could be validated before writing the properties file, unless the whole distribution indeed is downloaded on 
wrapper
task execution which would be pretty bad, as I said before.
c
./gradlew wrapper --gradle-distribution-url https\:<//services.gradle.org/distributions/whatever-the-zip-actually-8.5.zip>
will not upgrade my distribution until I run 
./gradlew
again
which means that the other files, like the jar I need to commit...
when I update wrapper
v
will not upgrade my distribution until I run 
./gradlew
again
Correct, it will update the properties file and generate the start scripts and jar from the version currently running
Because that you need to run the 
wrapper
task a second time if you want the jar and start scritps from the new version
c
whelp, I'm gonna call that broken and it should do it eagerly
v
🤷‍♂️
c
because I have trouble understanding why I don't want it to fetch it when I tell it to update
there's no real reason not to, imo
v
You don't tell it to update, you tell it to generate the wrapper files in a way that they work with a specific version
c
doing it this way can result in easily committed brokenness
v
Like any code change you do 😄
c
and if you're not using a vcs... repairing gradle means downloading gradle again...
v
not really
c
because you can't just create gradlew with a curl
v
Given you right now executed Gradle to break it, the distribution is still there and you can just call it to generate fresh files
c
ne-ways, even if I misunderstand the problem, my demo works right?
v
Or you can use the wrapper of another project
I never have Gradle installed anywhere
c
at least I said something?
v
Your demo code does break the properties file if the URL's HEAD request was successful, yes. I never questioned that. 🙂
c
Given you right now executed Gradle to break it, the distribution is still there and you can just call it to generate fresh files
I have no idea how to do that, because I don't know where that jar lives
it's not on my path
and gradlew is broken at that point
v
It's in the Gradle user home under 
wrapper/dists
c
and if I don't know what the previous thing looked like...
v
But as I said, you can also always just use the wrapper of another project for example
c
by I don't know, assume I"m an idiot and doesn't know
there's not an obvious fix
v
Ok, what if you don't know how to execute a shell script, then you also cannot figure out what to do with those 
gradlew
files.
c
I only know how to execute ./gradlew because that's what's documented
v
I presume minimal abilities if you are using Gradle
c
digging into wrapper/dists is not
v
If you are at a stage where you use a custom distribution URL, you are way beyond just using the documented 
./gradlew
c
you expect people to read every directory that gradle creates?
v
Where did I say that?
c
sadly, not really... those are required by the enterprise
I've litterally only cared what's in any gradle directory because of caching or needing to edit a file
I"ve never looked in that directory
v
All I said was, that you do not have to install a Gradle version just because you broke your wrapper which is what you stated, but that there are several other ways to mitigate the problem. You don't need to know them, you can Google them, you can ask here, you can find out by crawling your disk, whatever. I just said they are there.
And honestly, who writes sourcecode without any kind of SCM?
That's just an unrealistic presumption for anything above simple experimenting
c
sadly I recently had an interview where they said they avoided it because they wanted to own any code and didn't want to push to the client until they were done
so... cowboy coding still exists in the wild
v
So what? Git for example is fully locally, nothing is shared anywhere until you do
c
and I've run into a ton of developers that don't know how git revert works
dude, I facepalmed, what do you want from me
v
Not using Git for local development is just like holding a gun in front of your foot, and playing with the trigger
c
I'm glad I didn't get a job offer, it sounded awful
I'm just saying, while you can do what you're saying, I would have never thought of that, or looked there
v
Yeah, that's what asking for help is for if you messed up things badly. :-)
c
right, but a lot of people won't ask for help
I appear to be an exception to the rule
they fear being judged
and probably other things
v
Well, then they have to live with the consequences. 😄
c
sadly there are many members of the open source community that aren't you. They're dicks and they treat people who do dumb things badly
v
Who said I'm not a dick? 😄
c
I mean... I'm trying to give you some credit. You are probably in the top 10 easiest and most helpful people I've met in the open source community
❤️ 1
👌 1
You really don't want to know about the 10 worst
anyways, feel free to comment on the issue or whatever... but my objective is not being able to break the local install
👌 1
when I tell it to update
v
I only know how to execute ./gradlew because that's what's documented
digging into wrapper/dists is not
Just for completeness and because I indeed just accidentally stumbled over it, it is documented what can be found that directory and that there the downloaded distributions are. 🙂 https://docs.gradle.org/current/userguide/directory_layout.html
👍 1
c
I hadn't had that accident yet
I have the problem that gradle is powerful, but often doesn't DWIM and makes things that should be easy hard
I really shouldn't need to understand that piece of directory layout
would have been a better way of putting it. I don't know why it should ever come up
but then I don't know why gradlew isn't an executable jar...
the creation of gradlew itself is more complicated than it needs to be
v
There is not really such a thing as an executable jar, especially cross-platform. And the thing typically called executable jar provides little to no extra value over a start script and often even makes things worse. And I'm not even talking about bad-practice fat jars right now. :-)
Besides that it wouldn't change anything related to the current discussion
c
eh
regretting opening the "meta" ticket
it's just gonna get closed as it demonstrates a real problem, but it is not any of the individual problems
I don't see the point in providing an example of why you'd do 
wrapper --write-locks
that's not a buggy behavior it's just needed. Since locks are used though it's necessary to show it being run.
honestly so far I rather regret opening the tickets. I don't believe they'll see any traction
v
There are so many tickets and so less resources, so the majority of the tickets just cannot be handled in time. But without tickets nothing will change at all. I question the "meta" ticket too though, thought you create that in a row of yours just to track the upstream issues. :-)
c
I kind of wish that those resources would be less dedicated to features and just fix bugs for a while
most of the features I want exist, but I'm starting to find a lot of things that look unfinished and/or bugs
v
Like probably in most bigger software projects 🙂
👍 1
c
yeah...
le sigh
and one mans feature is another mans bug fix 😛
👍 1
😭
5 Views
Open in Slack
PreviousNext
Powered by