Cleanup build.gradle #1108
Cleanup build.gradle #1108
Conversation
|
While we're at it, I'd like to consider (in a separate PR) to remove the following functionality altogether:
@ArneBab can you confirm that you're not somehow using the Maven publish tasks, the .tar archive task, or Ant builds for releasing? |
|
Thank you for asking! I don’t use the maven publish tasks (that infrastructure is broken), but we do use the .tar archives for the internal auto-updates. MD5 sums are pretty useless, though. Also we should not become more dependent on github for our releases. We should not remove ant. I added it again, because gradle is horrible to package for distributions which leads quite a few of them to just not package it, so for distribution packages we should not ever require it. So yes on maven upload removal, and yes on running the tests (bombe fixed them a few months ago, so we can now run them), and yes on the cleanup, but no on removing the tar archives and on removing ant. |
|
I think we should move the Ant build to somewhere else. If we keep it with the official sources, technically everybody who touches something in the build infrastructure needs to do the same changes in the Ant build. Nobody will do that because #%$! Ant. If you, @ArneBab, are already the only person trying to keep the Ant build alive for packaging reasons (which IMHO is out-of-scope for Hyphanet itself), move it to a different repository. 🙂 |
| compileJava { | ||
| options.encoding = 'UTF-8' | ||
| if (!version.endsWith('-dirty')) { | ||
| // Make sure incremental compilation is disabled on release builds due to reproducibility issues. |
There was a problem hiding this comment.
Is this necessary? Release builds should not be made from random developer machines, should they? Don’t we have build infrastructure for that?
There was a problem hiding this comment.
To be fair I do not have a clue about what our build infrastructure looks like. This makes it somewhat less fragile to reproduce a build, though.
Necessary? Probably not. I'll be happy to drop 440aeee if you believe there's no merit to it - Arne will just have to ./gradlew clean assemble then. Just let me know what you prefer.
There was a problem hiding this comment.
Yeah, @ArneBab needs to chip in here, I also have no idea how our releases are built, I’m just hoping there’s an automated process that does not depend on a single developer’s machine. 😄
There was a problem hiding this comment.
If you want to see how our releases are built, check the sign-windows-installer workflow. It does the necessary preparations and then forwards to verify-build from the scripts repo.
So while inserting the releases is dependent on a single devs machine (though the keys are distributed via ssss, so if I join a circus, you can recreate them), building the release works in the github workflow, too.
We’d actually get an error during the windows release signing, if my setup produced a different jar (different as in the check in verify build) than the one in the workflow.
There was a problem hiding this comment.
The fred-release script does use gradlew jar without cleaning, so that'd be an argument to keep this code. Or to fix the release script 😄
|
I am not the only person. The ant build infrastructure is re-imported from the Gentoo ebuild (not maintained by me, but they did the work to actually cut out freenet-ext.jar and replace it by distro packages) and required in Gentoo, in Debian, and in Guix (these are the ones I know of). Gradle is simply a bad choice for tools that should be available in distributions. And in distributions is where we have to be, so while I did not consider it as important before, I nowadays think we should treat ant build support as requirement. We don’t need dependency checking for distributions, because they already do, and we don’t need to download dependencies. We only need "use a command to create a working freenet.jar from the source and dependencies in defined locations; bonus points for running the tests". |
bertm
force-pushed
the
cleanup-build-gradle
branch
from
24dbcd1 to
52e475f
Compare
Ooh, ooh, I know, I know! We should switch to Maven! 😄
That also means that in the future we need to pay attention to PRs that touch functionality that Ant needs. You probably already do that, but I sure as hell don’t… 🙂 |
Maven by now can have the plugin maven-lockfile, so it would be an option today. But I don’t know whether switching is worth all the cost surrounding it.
We could run the build via ant, too, with the dependencies pointing to the ones downloaded via gradle. |
|
Thank you both for chiming in!
Are you sure it's the Gradle-generated one? All the tar archives I can find in the scripts are created by
That's an interesting thought. We could run the Ant build after the Gradle one and check that they produce the exact same JAR contents (note: they currently don't - the new first-time wizard HTML page is missing in the Ant build - and the instructions in the README require adjustments to get it working at all). That'd allow us verify the Ant build script using Gradle as guardrails - and vice-versa. That's something for another PR though 😄
I'll file a PR for that after this one is done.
Thanks! That'll become another PR, too. |
I mean, a popular combination back in the day was Ant + Ivy, with Ivy taking care of the dependency management… |
Yes, but we decided against that back then. I don’t know whether it was the right decision, but it’s one we took, and by now switching away would have . Gradle provides the added value that people just need to do |
You’re right: we use git archive for the source tar, so gradle tar can likely go. |
Setting a property via the Gradle-generated 'propName value' or 'propName(value)' syntax in Groovy DSL has been deprecated.
The event was used to output archive digests after build completion. Replace this with a task `printArchiveDigests` and schedule it whenever an archive task is used, preferring execution after all other tasks.
The Version.java source file should always be regenerated whenever the version changes. Always compute the version and define it as an input so that the file is considered stale when the version changes.
If the sourceSets express our intention for compiling the source, Gradle can do pretty much all the heavy lifting without custom tasks. Refactor the sourceSets so that the custom tasks providing standard functionality can be removed: * `buildJar` is replaced by the java-plugin provided `jar` task * `compileVersion` is no longer a separate step, `compileJava` comsumes the sources (without the version file) and the generated version file * `sourcesJar` is replaced by the java-plugin provided `sourcesJar` task (enabled by specifying `withSourcesJar()`) * `copyResourcesToClasses2` and `copyTestResourcesToClasses2` are no longer needed as the resources are now declared in the sourceSets and automatically copied by Gradle * `copyRuntimeLibs` dependency on `jar` is implicit (from `from jar`) and does not need to be specified. * Reproducible build settings are now applied across all archival tasks
This includes the tasks in the listing generated by :tasks.
:copyRuntimeLibs depends on :jar, there is no need to invoke :jar first.
This task is never used in the release process. The archives it would create can be created more reliably using `git archive`.
bertm
force-pushed
the
cleanup-build-gradle
branch
from
52e475f to
fdfc24a
Compare
|
Rebased against |
3 participants
Our Gradle build is using various deprecated options and features (syntax, conventions and properties), and has various custom tasks for what is supposed to be standard Gradle functionality (such as dealing with sources, compilation, resources copying, and JARs). Additionally, the source version (in Version.java) was not always updated appropriately unless a
cleanbuild was done.Overhaul the
build.gradleconfiguration to get rid of deprecation warnings & make it more maintainable.Additionally, improve the following:
-PbuildXXXXX)gradlew assemble.@ArneBab could you please check that this did not break your release manager workflow?