main Changelog 3.3 === - 3.3.0 GradleUtils Shared stricter impl details, Gradle 9, Java 17 Dedicated `#report` and `#throwing` in enhanced problems Add enhanced plugin #rootProjectDirectory Documentation and shit 3.2 === - 3.2.25 Add `gradleutils#pluginDevDefaults` Does some convention defaults when invoked with the configurations container and the requested Gradle version. Helps to eliminate more unnecessary clutter in the buildscripts. - 3.2.24 Fix import failure on non-java projects - 3.2.23 Fix workaround for local Gradle API failing build I forgot about `Configuration#withDependencies`. But ups to Gradle's stellar documentation (i am lying) - 3.2.22 Fix gradleutils.unpack being inaccessible Was previously a static method but static methods are not passed down from inherited interfaces to the implementation classes. At least not for Groovy objects(?) Static fields continue to work though. Super weird. - 3.2.21 Fix workaround for local Gradle API suppression not working - 3.2.20 Fix ToolExecBase tasks not serializing with the config cache - 3.2.19 Added some gradle properties `net.minecraftforge.gradleutils.ide.automatic.sources` - Enabled if set to `true`. - Automatically downloads sources and JavaDocs on IntelliJ IDEA or Eclipse. `net.minecraftforge.gradleutils.compilation.defaults` - Enabled if set to `true`. - Sets all Java, Groovy, and Javadoc compilation tasks to encode in UTF-8. - Sets Groovy compilation tasks to compile with the Indy optimization. - Sets a human-readable window title for Javadoc and Groovydoc tasks using either `gradleutils.displayName` or `project.name`. - Sets the apiNote, implNote, and implSpec tags for Javadoc tasks. - Emits a warning if there is an enabled Groovydoc task but the default charset is not UTF-8. - It is a Gradle limitation that Groovydoc is invoked via its internal ant builder rather than in a forked JVM. - 3.2.18 Honor system property to suppress Gradle API This applies a workaround to gradle/plugin-portal-requests#260 when the Shadow plugin is applied where the local Gradle API is added to the `compileOnly` configuration even if the `org.gradle.unsafe.suppress-gradle-api` system property is used. Which, we do. This workaround is written in a way that even after this is fixed by the Plugin Publish plugin, it won't break anything. It just helps remove some clutter from the buildscript. - 3.2.17 Add gradleutils.displayName Useful as an external property to store the display name so it can be accessed in places other than the project or buildscript. Also, used for optional features which can be enabled with a property flag. - 3.2.16 Use new Git Version plugin updates - 3.2.15 New instantiation strategy for various things Despite being a dynamic build service, Gradle has static service registries for objects that have already been instantiated. Working around this by taking advantage of the project when available. This only affects configuration time and does not cause caching issues. - 3.2.14 Fix plugins not using ToolsExtension failing build - 3.2.13 Additional helper methods for adding arguments in ToolExecBase - 3.2.12 Fix failing to apply on projects without 'java' plugin - 3.2.11 Work around a weird Gradle bean injection issue - 3.2.10 Allow external configuration for additional args in ToolExecBase In case buildscripts need to define additional arguments that cannot be added to the task itself. - 3.2.9 Remove Gradle version attribute from the shared library The Gradle version attribute is primarily used to enforce that a specific Gradle version is used for a plugin. Since the GradleUtils Shared library is not a plugin, this causes issues if added as a dependency because Gradle will indescriminately check the current daemon's running Gradle version even if it has nothing to do with its application. Since this is an internal library, I am not going to enforce the Gradle API dependency constraint on this library, especially since the Gradle API artifact is not centralized or declares any capabilities. But, if non-Forge consumers wish to use GradleUtils Shared for their plugins, it is up to them to make sure their implementation Gradle version is high enough. As if right now, it is 8.13. - 3.2.8 Add `#unpack` helper method to gradleutils - 3.2.7 Opt-in tool definition override for plugins - 3.2.6 Fix flow actions causing null pointer exception in some cases - 3.2.5 Allow usage of #launcherFor without the 'java' plugin Not all Gradle plugins are required to apply the 'java' plugin. This means that for plugins which need a Java launcher for a task and/or JavaExec(Spec), we need to be flexible to avoid locking in projects into needing that plugin. I've locked down the SharedUtil methods for getting Java launchers. #launcherFor requires Project and #launcherForStrict requires JavaToolchainService (provided by JavaExecSpec, or can be injected at project configuration). If no Java toolchain or 'java' plugin, `JavaLanguageVersion#current` will be used to compare to the required Java version to run. As a reminder, breaking changes are permitted for `gradleutils-shared` as it must only ever be shadowed by plugins that use it. - 3.2.4 Cleaned up internal problem reporting - 3.2.3 Fix SharedUtil#toLog not actually working - 3.2.2 Add flag to set publication artifact ID from base.archivesName Apologies for forgetting how unbelievably inconsistent Gradle can be. The project's `base.archivesName` is used as the base name for archives, but that name isn't used for publications even though it's used for the archives. It's deep in internals, but publication name is set by `project.name`. When writing our buildscripts, I was under the impression that `base.archivesName` was used for the artifact ID for publications. Thankfully, most of our projects already use the project name as the artifact ID, so there has been no impact. I've added it in GradleUtils but it's disabled by default. You can use it by setting this flag in your `gradle.properties`: ```properties net.minecraftforge.gradleutils.publishing.use-base-archives-name=true ``` - 3.2.1 Make EnhancedProblems serializable and no longer extend Problems Addresses known issues with custom objects implementing the `Problems` interface. Also allows for cleanup in ToolExecBase where the enhanced problems isntance would need to be recalculated at execution time, it can instead now serialize the enhanced problems instance. This *does not* affect existing plugins as all plugins must shadow the shared base. No changes need to be made when updating the shared base, just a re-compile. - 3.2.0 Stabilize publication promotion Publication promotion (also known as artifact promotion) promotes a published publication on the Forge files site to become the "latest" version it displays. It also updates the files site and makes it aware of the new version of the project that was just pushed to the maven. This is designed for internal use only by Forge projects, or for projects that have trusted access to the Forge maven. However, it is not a requirement for all Forge projects to be promoted on the files site. As a reminder, promotion is requested like this in your buildscript (Groovy DSL): ```groovy publishing { repositories { maven gradleutils.publishingForgeMaven } publications.register('pluginMaven', MavenPublication) { gradleutils.promote(it) // ... } } ``` 3.1 === - 3.1.4 Fix illegal usage of TaskProvider#configure after evaluation I'm on a roll today 😔 - 3.1.3 Fix task creation ignoring input publication - 3.1.2 Allow promotion task to be configured - 3.1.1 Applying GradleUtils on projects not working - 3.1.0 Re-introduce artifact promoting Still experimental. Will only work if the publishing Forge maven is added to the publishing repos. The promotion task will become a finalizer of the relevant publish task (i.e. `publishMavenJavaPublicationToForgeRepository`). You can promote a publication by doing this: ```groovy publishing { repositories { maven gradleutils.publishingForgeMaven } publications.register('pluginMaven', MavenPublication) { gradleutils.promote(it) // ... } } ``` 3.0 === - 3.0.0 3.0 Full Release