Gradle 3.0 is the next major Gradle release that offers the opportunity to make breaking changes to the public interface of Gradle. This document captures a laundry list of ideas to consider before shipping Gradle 3.0.
Note: for the change listed below, the old behaviour or feature to be removed should be deprecated in a Gradle 2.x release. Similarly for changes to behaviour.
The following stories are candidates to be included in a major release of Gradle. Currently, they are not scheduled to be included in Gradle 3.0.
The current defaults for the outputs of tasks of type Test
conflict with each other:
- Change the default result and report directory for the
Test
type to include the task's name, so that the default does not conflict with the default for any otherTest
task. - Change the default TestNG output directory.
- Remove
--no-color
command-line option. - Remove
LoggingConfiguration.colorOutput
property. - Remove
LoggingManager.logLevel
property. Managing the log level should not be a concern of the build logic. - Remove
Project.getLogging()
method. Would be replaced by the existinglogging
property onScript
andTask
. - Move internal types
StandardOutputCapture
,StandardOutputRedirector
andLoggingManagerInternal
into an internal package.
- Remove
org.gradle.api.tasks.bundling.Jar
, replaced byorg.gradle.jvm.tasks.Jar
. - Move defaults for output directory and other attributes from the base plugin to an implicitly applied plugin, so that they are applied to all instances.
- Use
${task.name}.${task.extension}
as the default archive name, so that the default does not conflict with the default for any other archive task.
- Cross version tests no longer test against anything earlier than 1.0
- Local artifact reuse no longer considers candidates from the artifact caches for Gradle versions earlier than 1.0
- Wrapper does not support downloading versions earlier than 1.0
- Remove old unused types that are baked into the bytecode of tasks compiled against older versions (eg
ConventionValue
). Fail with a reasonable error message for these task types.
Building against Java 5 requires that the compiler daemon and test execution infrastructure still support Java 5.
- Clean up
DefaultClassLoaderFactory
. - Change
InetAddressFactory
so that it no longer uses reflection to inspectNetworkInterface
. - Replace usages of
guava-jdk5
.
Now we have real incremental Java compilation, remove the CompileOptions.useDepend
property and related options.
- Remove the remaining Open API interfaces and stubs.
- Remove the
openApi
project.
Alternatively, default the group to null
and status to integration
.
- Change the default for
useAnt
tofalse
and deprecate theuseAnt
property. - Do a better job of matching up the target jvm version with the scala compiler backend.
Currently required for in-process Ant-based compilation on Java 5. Dropping support for one of (in-process, ant-based, java 5) would allow us to remove this.
- Change the old publishing DSL to use the Maven 3 classes instead of Maven 2 classes. This affects:
MavenResolver.settings
MavenDeployer.repository
andsnapshotRepository
.MavenPom.dependencies
.
- Remove
MavenDeployer.addProtocolProviderJars()
. - Change
PublishFilter
so that it accepts aPublishArtifact
instead of anArtifact
.
There are several inconsistencies and confusing behaviours in the copy tasks and copy spec:
- Change copy tasks so that they no longer implement
CopySpec
. Instead, they should have acontent
property which is aCopySpec
that contains the main content. Leave behind some methods which operate on the file tree as a whole, egeachFile()
,duplicatesStrategy
,matching()
. - Change the copy tasks so that
into
always refers to the root of the destination file tree, and thatdestinationDir
(possibly with a better name) is instead used to specify the root of the destination file tree, for those tasks that produce a file tree on the file system. - Change the
Jar
type so that there is a singlemetaInf
copy spec which is a child of the main content, rather than creating a new copy spec each timemetainf
is referenced. Do the same forWar.webInf
. - The
CopySpec.with()
method currently assumes that a root copy spec is supplied with all values specified, and no values are inherited by the attached copy spec. Instead, changeCopySpec.with()
so that values are inherited from the copy spec.- Change
CopySpec
so that property queries do not query the parent value, as a copy spec may have multiple parents. Or, alternatively, allow only root copy spec to be attached to another usingwith()
.
- Change
- Change the default duplicatesStrategy to
fail
or perhapswarn
. - Change the
Ear
type so that the generated descriptor takes precedence over a descriptor in the main content, similar to the manifest forJar
and the web XML forWar
.
The old dependency result graph is expensive in terms of heap usage. We should remove it.
- Promote new dependency result graph to un-incubate it.
- Remove methods that use
ResolvedDependency
andUnresolvedDependency
. - Keep
ResolvedArtifact
and replace it later, as it is not terribly expensive to keep.
Some model types hand-code the DSL conventions in their API. We should remove these and let the DSL decoration take care of this, to simplify these types and to offer a more consistent DSL.
- Remove all methods that accept a
Closure
when anAction
overload is available. Add missing overloads where appropriate. - Remove all methods that accept a
String
orObject
when a enum overload is available. Add missing overloads where appropriate. - Remove CharSequence -> Enum conversion code in
DefaultTaskLogging
. - Remove all set methods that contain no custom logic.
- Formally document the Closure → Action coercion mechanism
- Needs to be prominent enough that casual DSL ref readers understand this (perhaps such Action args are annotated in DSL ref)
LongRunningOperation.withArguments()
should be calledsetArguments()
for consistency.- Remove support for consumers older than 1.6, will allow the provider to drop support for
BuildActionRunner
protocol. - Remove the old
ProgressListener
interfaces and methods. These are superseded by the new interfaces. However, the new interfaces are supported only by Gradle 2.5 and later, so might need to defer the removal until 4.0. - Move
UnsupportedBuildArgumentException
andUnsupportedOperationConfigurationException
up toorg.gradle.tooling
, to remove package cycle from the API.
- Remove the
<<
operator. - Inline
ConventionTask
andAbstractTask
intoDefaultTask
. - Remove
Task.dependsOnTaskDidWork()
. - Mix
TaskInternal
in during decoration and remove references to internal types.
- Remove
Configurable
from public API types. - Remove
PomFilterContainer.getActivePomFilters()
. - Change
StartParameter
so that it no longer extendsLoggingConfiguration
. - Move
ConflictResolution
from public API (it's only used internally). - Move
Module
from public API (it's only used internally). - Move
Logging.ANT_IVY_2_SLF4J_LEVEL_MAPPER
from public API. - Move
AntGroovydoc
andAntScalaDoc
from public API. - Move
BuildExceptionReporter
,BuildResultLogger
,TaskExecutionLogger
andBuildLogger
out of the public API.
Extension objects have been available for over 2 years and are now an established pattern.
- Migrate core plugins to use extensions.
- Remove
Convention
type.
- Project should not delegate to its build script for missing properties or methods.
- Project should not delegate to its parent for missing properties or methods.
- Project build script classpath should not inherit anything from parent project.
- Remove the specialised subclasses of
UnknownDomainObjectException
and the overridden methods that exist simply to declare this fromPluginContainer
,ArtifactRepositoryContainer
,ConfigurationContainer
,TaskCollection
. - Remove the specialised methods such as
whenTaskAdded()
fromPluginCollection
,TaskCollection
- Remove the
extends T
upper bound on the type variable ofDomainObjectCollection.withType()
. - Remove the type variable from
ReportContainer
- Remove unused constants from
ArtifactRepositoryContainer
- Move
ReportContainer.ImmutableViolationException
to make top level.
- Remove
equals()
implementations fromDependency
subclasses. - Remove
ExternalDependency.force
. Use resolution strategy instead. - Remove
SelfResolvingDependency.resolve()
methods. These should be internal and invoked only as part of resolution. - Remove
ClientModule
and replace with consumer-side component meta-data rules. - Remove
ExternalModuleDependency.changing
. Use component meta-data rules instead.
- Remove the public
StartParameter
constructor. - Remove the public
StartParameter
constants,GRADLE_USER_HOME_PROPERTY_KEY
andGRADLE_USER_HOME_PROPERTY_KEY
. - Change
StartParameter
into an interface.
- Replace
TaskDependency.getDependencies(Task)
withTaskDependency.getDependencies()
. - Remove constants from
ExcludeRule
. - Rename
IllegalDependencyNotation
to addException
to the end of its name. - Remove
ConventionProperty
, replace it with documentation. - Remove
Settings.startParameter
. Can usegradle.startParameter
instead. - Remove
org.gradle.util
from default imports. - Remove
AbstractOptions
. - Remove or rename
Logging.ANT_IVY_2_SLF4J_LEVEL_MAPPER
. - Remove unused
EclipseDomainModel
. - Replace
ShowStacktrace.INTERNAL_EXCEPTIONS
withNONE
.
Promote the sonar-runner
plugin and remove the sonar
plugin.
SignatoryProvider
and sub-types should use container DSL instead of custom DSL.
Decorating classes at load time is generally a more reliable approach and offers a few new interesting use cases we can support. For example, by decorating classes
at load time we can support expressions such as new MyDslType()
, rather than requiring that Gradle control the instantiation of decorated objects.
Switching to decoration at load time should generally be transparent to most things, except for clients of ProjectBuilder
that refer to types
which are not loaded by Gradle, such as the classes under test.
- Rename buildDependents to buildDownstream
- Rename buildNeeded to buildUpstream
- Add a new task buildStream which is equivalent to buildDownstream buildUpstream
- A Gradle best pattern is to name the gradle file to be the same name as the subproject.
- Let's support this out of the box, possibly as a preference to
build.gradle
, and maybe drop support forbuild.gradle
in subprojects.