From d1747794dbdc977fbb0a9dcc80e669bff52904ec Mon Sep 17 00:00:00 2001 From: Rene Groeschke Date: Wed, 17 Apr 2013 01:14:36 +0200 Subject: [PATCH] Master is now on 1.7; reset release notes --- subprojects/docs/src/docs/release/notes.md | 230 ++------------------- version.txt | 2 +- 2 files changed, 20 insertions(+), 212 deletions(-) diff --git a/subprojects/docs/src/docs/release/notes.md b/subprojects/docs/src/docs/release/notes.md index 44c5c3c72939..68b9ed7478af 100644 --- a/subprojects/docs/src/docs/release/notes.md +++ b/subprojects/docs/src/docs/release/notes.md @@ -2,159 +2,20 @@ Here are the new features introduced in this Gradle release. -### Installation via Gradle Wrapper is now multi process safe + -In previous versions of Gradle it was possible for a Gradle distribution installed implicitly via the [Gradle Wrapper](userguide/gradle_wrapper.html) to be corrupted, -or to fail to install, if more than one process was trying to do this at the same time. This was more likely to occur on a continuous build server than a developer workstation. -This no longer occurs as the installation performed by the wrapper is now multi process safe. +## Promoted features -**Important:** leveraging the new multi process safe wrapper requires updating the `gradle-wrapper.jar` that is checked in to your project. -This requires an extra step to the usual wrapper upgrade process. +Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. +See the User guide section on the “[Feature Lifecycle](userguide/feature_lifecycle.html)” for more information. -First, update your wrapper as per usual by updating the `gradleVersion` property of the wrapper task in the build… +The following are the features that have been promoted in this Gradle release. - task wrapper(type: Wrapper) { - gradleVersion = "1.6" - } - -Then run `./gradlew wrapper` to update the wrapper definition. This will configure the wrapper to use and download Gradle 1.6 for future builds, -but it has not updated the `gradle-wrapper.jar` that is checked in to your project. To do this, simply run `./gradlew wrapper` again. This is necessary as the wrapper -jar is sourced from the Gradle environment that is running the build. - -If you are seeding a new project using an installation of Gradle 1.6 or higher, you do not need to run the wrapper task twice. It is only necessary when upgrading the -wrapper from an older version. - -### Force a task to run after another task, without adding a dependency (i) - -In the past, the only way to ensure that Gradle ran one task after another was to add a dependency between those tasks. So if `Task A` must always run before `Task B`, you would - say that `B.dependsOn(A)`. This has the added effect of forcing `Task A` to always run if `Task B` is executed. - -In some cases, `dependsOn` is not the correct semantics. A simple example is “clean” must always run before “build”, but you don't always want to run “clean” whenever you run “build”. -For this use case Gradle now has “task ordering” rules, the first of which is `Task.mustRunAfter`. -This rule does not change which tasks will be executed, but it does influence the order in which they will be executed. - - task clean { ... } - task build { ... } - - build.mustRunAfter clean - -In this example you can still execute `gradle clean` and `gradle build` independently, but running `gradle build clean` will cause 'clean' to be executed before 'build'. - -Another example is a test-aggregation task that consumes the outputs of all of the test tasks. -You want this aggregation task to run _after_ all test tasks, but you do not necessarily want to force all test tasks to run. - - task runUnitTests(type: Test) { ... } - task runIntegTests(type: Test) { ... } - task createTestReports { ... } - - tasks.withType(Test) { testTask -> - createTestReports.mustRunAfter(testTask) - } - - task allTest(dependsOn: [runUnitTests, runIntegTests, createTestReports]) // This will run unit+integ tests and create the aggregated report - task unitTest(dependsOn: [runUnitTests, createTestReports]) // This will run unit tests only and create the report - task integTest(dependsOn: [runIntegTests, createTestReports]) // This will run integ tests only and create the report - -Note that it would not be suitable to use `createTestReport.dependsOn(runUnitTests)` in this case, -since that would make it difficult to execute the integration tests and generate the report, _without_ running the unit tests. -The `mustRunAfter` task ordering rule makes it easy to wire this logic into your build. - -See the User guide section on “[Ordering Tasks](userguide/more_about_tasks.html#sec:ordering_tasks)” for more information. - -On behalf of the Gradle community, the Gradle development team would like to thank [Marcin Erdmann](https://github.com/erdi) for taking on this long anticipated feature. -The design and implementation of task ordering rules involved a deep understanding and refactoring of the Gradle Task execution engine, and Marcin took this on with gusto. - -### JaCoCo Code Coverage Plugin (i) - -Gradle now ships with a [JaCoCo](http://www.eclemma.org/jacoco/) plugin to generate code coverage reports. JaCoCo is a free code coverage library for Java. - -To gather code coverage information for your java project, just apply the JaCoCo plugin: - - apply plugin: 'jacoco' - -and run `gradle test jacocoTestReport` which generates code coverage reports for the “test” task introduced by the `java` plugin. The `JacocoReport` adds a `mustRunAfter` dependency on the -coverage data producing task ('test' in our example). After the build has finished you find the coverage report in different formats in `build/reports/jacoco/test`. - -You can configure every task of type `JacocoReport` to enable other output formats than the default `HTML` report. For example, if you just want the `xml` coverage report that can be reused by your -favourite CI server, you can simply configure this: - - jacocoTestReport { - reports { - html.enabled = false - csv.enabled = false - xml.enabled = true - } - } - -In some scenarios it might be desirable to compute code coverage not by running tests, but by running the application itself. -Since the JaCoCo plugin can be used in combination with any `JavaExec` task of your build, it's quite simple to combine the `JaCoCo` plugin with the `run` task introduced by the `application` plugin: - - jacoco { - applyTo run - } - - task applicationCodeCoverageReport(type: JacocoReport) { - executionData run - sourceSets sourceSets.main - } - -This plugin was contributed by [Andrew Oberstar](https://github.com/ajoberstar), an energetic member of the Gradle community, and is a long requested out-of-the-box feature that is a very welcome addition. - -### Build Setup Plugin (i) - -Gradle 1.6 introduces a `build-setup` plugin that makes initializing new Gradle projects more convenient. -It also supports bootstrapping the migration of an Apache Maven build to a Gradle build by generating a `build.gradle` file from a `pom.xml`. - -The `build-setup` plugin is not a plugin that you manually apply to your project. You use it by executing the `setupBuild` task in a directory that does not contain a `build.gradle` file. - -Running `gradle setupBuild` in a directory with no `build.gradle` file will do the following: - -* If a `pom.xml` exists, a `build.gradle` file is generated based on its content (e.g. equivalent dependency definitions). -* If no `pom.xml` exists, an empty `build.gradle` file is generated. -* The [Gradle Wrapper](userguide/gradle_wrapper.html) is installed for the project. - -For more information please see the [User Guide chapter on this plugin](userguide/build_setup_plugin.html). - -This plugin is an *incubating* feature and will improve and expand in scope in future releases. -If you're interested in its progress and future, you can check out the [design spec](https://github.com/gradle/gradle/blob/master/design-docs/build-initialisation.md). - -### Support for JUnit @Category (i) - -Thanks to a contribution by [Uladzimir Mihura](https://github.com/trnl), Gradle now supports [JUnit categories](https://github.com/junit-team/junit/wiki/Categories). -Categories are a mechanism to label and group JUnit tests by using annotations. - -Given the following JUnit test code: - - public interface FastTests { /* category marker interface */ } - public interface SlowTests { /* category marker interface */ } - - public class MyTestClass { - @Category(SlowTests.class) - @Test public void testA() { - … - } - - @Category(FastTests.class) - @Test public void testB() { - … - } - } - -You can now easily configure your test task to run only specific categories: - - test { // run fast unit test only - useJUnit { - includeCategories 'org.gradle.categories.FastTests' - excludeCategories 'org.gradle.categories.SlowTests' - } - } - -The `includeCategories` and `excludeCategories` are methods of the [JUnitOptions](groovydoc/org/gradle/api/tasks/testing/junit/JUnitOptions.html) object and take -the full class names of one or more category annotations to include or exclude. - -### Plugins can expose custom tooling models via the tooling API - -TODO + ## Fixed issues @@ -165,76 +26,23 @@ in the next major Gradle version (Gradle 2.0). See the User guide section on the The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the [Gradle Forums](http://forums.gradle.org). -### `StartParameter.getMergedSystemProperties()` method is deprecated - -This method is no longer used internally so it does not make sense to keep it in the public API. - -### `groovy` configuration is deprecated - -Since Gradle 1.4, the preferred way to specify the Groovy library is to add it to the `compile` (or `testCompile`) configuration, rather than the `groovy` configuration. -Therefore, the `groovy` configuration is now deprecated. Simply replace `groovy` with `compile` in the `dependencies` block: - - dependencies { - compile "org.codehaus.groovy:groovy-all:2.0.6" - } - -In some cases (for example if the Groovy Jar has been renamed), it may also be necessary to explicitly configure the `groovyClasspath` of `GroovyCompile` and `Groovydoc` tasks. - -For additional background information about this change, see the [Groovy chapter](userguide/groovy_plugin.html#N1289B) of the Gradle user guide. + ## Potential breaking changes -### `org.gradle.api.artifacts.ProjectDependency` and `org.gradle.api.plugins.ExtensionContainer` now have an internal protocol - -This means that the users should not create own implementations of `org.gradle.api.artifacts.ProjectDependenc` or `org.gradle.api.plugins.ExtensionContainer`. -This change should not affect any builds because there are no known use cases supporting custom instances of these API classes. - -### Renamed `add()` method on PublicationContainer (incubating) - -The [org.gradle.api.publish.PublicationContainer](javadoc/org/gradle/api/publish/PublicationContainer.html) introduced by the incubating publish plugins leverages the new support for -polymorphic domain object containers in Gradle. This change involved switching from the custom `add` methods to the standard `create`. -The semantics of the replacement methods is identical to those replaced. - -This change does not effect publications added to the PublicationContainer using [a configuration block](javadoc/org/gradle/api/publish/PublishingExtension.html#publications), -but will impact publications added directly using `add()`. - -### Changes to exceptions thrown on project evaluation - -The exception thrown by Gradle when on build script error or other configuration problem has changed. All such exceptions are now chained in ProjectConfigurationException. -This change will only impact code that explicitly catches and processes an exception thrown by Gradle when configuring a project. - -### Incubating `StartParameter.isParallelThreadCountConfigured()` method removed - -It is not needed internally and it shouldn't be needed by the users, too. - -### Upper bound removed from Tooling API `org.gradle.tooling.ModelBuilder` - -With the introduction of support for custom tooling API models, the tooling API models are no longer required to extend the `org.gradle.tooling.model.Model` marker -interface. The upper bound `extends Model` has been removed from the type parameter of `ModelBuilder`. - -### Tooling API `org.gradle.tooling.ProjectConnection.model()` no longer throws `UnknownModelException` - -With the introduction of support for custom tooling API models, it is no longer possible to determine whether a model is supported without -configuring the target build. This exception is now thrown as part of the result. - -### Wrapper environment variable `GRADLE_WRAPPER_ALWAYS_UNPACK` and `GRADLE_WRAPPER_ALWAYS_DOWNLOAD` no longer supported - -The Gradle wrapper no longer supports the `GRADLE_WRAPPER_ALWAYS_UNPACK` and `GRADLE_WRAPPER_ALWAYS_DOWNLOAD` environment variables. -Instead, the wrapper is now much better at recovering from failures to download or unpack the distribution. - -### More packages included in default imports - -The set of default imports is now generated from the Gradle API. This means that the default imports now includes a number of additional packages -that were not previously imported by default. These packages may contain classes that conflict with other imports present in your build scripts. + ## External contributions We would like to thank the following community members for making contributions to this release of Gradle. -* [Marcin Erdmann](https://github.com/erdi) - added the ability to schedule one task to always run after another, without adding a hard dependency. -* [Andrew Oberstar](https://github.com/ajoberstar) - added the JaCoCo code coverage plugin. -* [Uladzimir Mihura](https://github.com/trnl) - provide first-class support for JUnit @Category (GRADLE-2111). -* [Xavier Ducrohet](https://github.com/ducrohet) - fix Success Rate display in test report overview page (GRADLE-2729). + We love getting contributions from the Gradle community. For information on contributing, please see [gradle.org/contribute](http://gradle.org/contribute). diff --git a/version.txt b/version.txt index dc39e58d9605..d3bdbdf1fdae 100644 --- a/version.txt +++ b/version.txt @@ -1 +1 @@ -1.6 \ No newline at end of file +1.7