Merge master into release in preparation for Gradle 2.0 release

CONTRIBUTING.md

@@ -19,7 +19,7 @@ You'll need to sign one of these before any code contributions will be accepted
 (Currently, the signed CLA must be posted or scanned/emailed directly to Gradleware. We're still working on our electronic signing process).
     1. Download, print and fill out the CLA, entering all of the requested personal information (Name, E-Mail, Mailing Address, Telephone, Country).
     2. Sign the CLA.
-    3. Post the document to one of the Gradleware offices listed at http://www.gradleware.com/contact, or scan and email the document to [email protected].
+    3. Post the document to one of the Gradleware offices listed at http://www.gradleware.com/contact, or scan and email the document to [email protected] (please include your GitHub username in the email or letter so we know who you are).
 2. Before starting to work on a feature or a fix, it's generally a good idea to open a discussion about your proposed changes on the Gradle Developer List ([email protected]). 
 Doing so helps to ensure that:
     1. You understand how your proposed changes fit with the strategic goals of the Gradle project.

build.gradle

@@ -18,6 +18,7 @@ import org.gradle.build.Install
 import org.gradle.build.BuildTypes
 import org.gradle.build.TestReportAggregator
 
+
 defaultTasks 'assemble'
 apply plugin: 'java-base'
 archivesBaseName = 'gradle'
@@ -110,6 +111,7 @@ apply from: "gradle/classycle.gradle"
 apply from: "gradle/noDependencyResolutionDuringConfiguration.gradle"
 apply from: "gradle/testSetup.gradle"
 apply from: "gradle/testGroupings.gradle"
+apply from: "gradle/analytics.gradle"
 
 allprojects {
     group = 'org.gradle'
@@ -158,6 +160,7 @@ dependencies {
     runtime project(':wrapper')
     gradlePlugins pluginProjects
     gradlePlugins project(':coreImpl')
+    gradlePlugins project(':pluginUse')
 }
 
 task verifyIsProductionBuildEnvironment << {

buildSrc/src/main/groovy/org/gradle/build/docs/dsl/docbook/JavadocConverter.java

@@ -330,6 +330,7 @@ private HtmlElementTranslatingHandler(DocBookBuilder nodes, Document document) {
             elementToElementMap.put("ol", "orderedlist");
             elementToElementMap.put("li", "listitem");
             elementToElementMap.put("em", "emphasis");
+            elementToElementMap.put("strong", "emphasis");
             elementToElementMap.put("i", "emphasis");
             elementToElementMap.put("b", "emphasis");
             elementToElementMap.put("code", "literal");

buildSrc/src/test/groovy/org/gradle/build/docs/dsl/docbook/JavadocConverterTest.groovy

@@ -287,6 +287,16 @@ literal code</programlisting><para> does something.
         format(result.docbook) == '''<para><emphasis>text</emphasis></para>'''
     }
 
+    def convertsAStrongElementToAnEmphasisElement() {
+        _ * classMetaData.rawCommentText >> '<strong>text</strong>'
+
+        when:
+        def result = parser.parse(classMetaData, listener)
+
+        then:
+        format(result.docbook) == '''<para><emphasis>text</emphasis></para>'''
+    }
+
     def convertsBAndIElementToAnEmphasisElement() {
         _ * classMetaData.rawCommentText >> '<i>text</i> <b>other</b>'
 

design-docs/component-metadata.md

@@ -132,12 +132,13 @@ Add a "changing" property to `ComponentMetadataDetails`.
     * Static dependency
     * Dynamic dependency (that is, the dependency may refer to different components over time, but the components themselves do not change)
 
-## Use Ivy extra attributes to determine status of module
+## Use Ivy extra info properties to determine status of module
 
-This story makes extra attributes defined in ivy.xml files available to component metadata rules, on request.
+An ivy.xml `<info>` element permits arbitrary child elements with string values. This story makes these extra info properties available to component metadata rules,
+on request.
 
-A rule should declare that these extra attributes form an input to the rule, in which case they will be provided.
-While this is perhaps not important for Ivy extra attributes, which are cheap to determine, this will be more important for
+A rule should declare that these extra info properties form an input to the rule, in which case they will be provided.
+While this is perhaps not important for Ivy properties, which are cheap to determine, this will be more important for
 Artifactory properties (see below).
 
 A medium-term goal is to sync the Component Metadata Rules DSL with the new general-purpose Rules DSL. So the same mechanism will be
@@ -146,59 +147,42 @@ simply attempt to introduce a DSL to declare such rules.
 
 ### User visible changes
 
-Option1: Typed ComponentMetadataDetails:
-
-    componentMetadata {
-        eachComponent { IvyModuleMetadataDetails details ->
-            if (details.ivyExtraAttributes['my-custom-attribute'] == 'value') {
-                details.status == 'release'
-            }
-        }
+    interface IvyModuleDescriptor {
+        Map<String, String> extraInfo
     }
 
-Option2: Additional parameters:
-
     componentMetadata {
-        eachComponent { ComponentMetadataDetails details, IvyExtraAttributes ivyAttributes ->
-            if (ivyAttributes['my-custom-attribute'] == 'value') {
+        eachComponent { ComponentMetadataDetails details, IvyModuleDescriptor ivyModule ->
+            if (ivyModule.extraInfo['my-custom-attribute'] == 'value') {
                 details.status == 'release'
             }
         }
     }
 
-Option3: Limit rule applicability (this might be useful in addition to one of the above):
-
-    componentMetadata {
-        eachComponent.withType(IvyModule) {
-            if (it.ivyAttributes['my-custom-attribute'] == 'value') {
-                it.status == 'release'
-            }
-        }
-    }
-
-    // This could later be extended with
-    eachComponent.withType(IvyModule).matching({ group == 'myorg' }) {
-        // custom rule that only applies to my internal modules
-    }
-
 ### Implementation
 
 * Add a model for Ivy-specific module metadata and make this available via `ModuleVersionMetaData`
+    * Include any name/value pairs defined as child elements of the `<info>` element. Do not include the namespace qualifier.
     * The actual values should already be available (and cached) via the underlying Ivy ModuleDescriptor
-    * The API should assume that a number of custom domain metadata elements may be present
-* For any rule defined that requires Ivy extra attributes to be processed, then Ivy extra attributes will be made available as per the DSL chosen
+    * The API should assume that other metadata models may be present as well
+* For any rule that declares IvyModuleDescriptor as an input:
+    * Provide the IvyModuleDescriptor as input where the resolved module came from an ivy repository
+    * Do not execute the rule where the resolved module does not have an associated ivy.xml file
 
 ### Test coverage
 
-* Publish with arbitrary extra attributes, and ensure these are available in resolve.
+* Publish with arbitrary extra info properties, and ensure these are available in resolve.
 * Publish again with changed values:
     * Original values are take from cache
     * New values are obtained when changing module is refreshed
-* Component metadata rule does not have access to ivy extra attributes if not declared as rule input
+* Component metadata rule does not have access to ivy extra info properties if not declared as rule input
 * Component metadata rule is not evaluated for non-ivy module when rule declares ivy attributes as input
 * Resolve with rule that does not have ivy extra attributes as input. Modify rule to include those inputs and resolve again
   Attributes are made available to rule (extra HTTP requests are OK, but not required).
 
+### Open issues
+
+
 ## Use Artifactory properties to determine status of module
 
 This story makes it possible to access published Artifactory properties from within a Component Metadata Rule:

design-docs/continuous-delivery-for-c-plus-plus.md

@@ -570,6 +570,7 @@ The implementation will also remove stale object files.
 
 - Need to handle `#import` with Visual C++, which may reference a `.tld` file.
 - Should not parse headers that we deem to be unchanging: 'system' libraries, unchanging repository libraries, etc.
+- Implementation currently locks the task artifact cache while compiling
 
 ## Story: Modify command line arguments for binary tool prior to execution
 
@@ -1121,6 +1122,8 @@ This story introduces a set of headers that are visible to all the source files
 
 - Default location for the implementation headers
 - Rename `lib()` to `dependsOn()` or similar?
+- Model 'implicit' headers: in the same directory as the source files or included via relative path.
+    - Need to make these available in the IDE and include in compile task inputs
 
 ### Story: Introduce public headers for native libraries
 
@@ -1239,6 +1242,7 @@ This story moves definition and configuration of the source sets for a component
   built-in tools.
 - Fix `TargetPlatformConfiguration` and `PlatformToolChain` to make them extensible, so that not every configuration supports every tool.
 - Gcc and Clang tool chains need to provide the correct compile and link time arguments on OS X and Linux.
+- Add test coverage on Windows
 
 ### Story: Incremental compilation for Objective-C and Objective-C++
 
@@ -1267,6 +1271,8 @@ this consistent with the way that tool arguments are configured in a tool chain.
 * Replace `PlatformConfigurableToolChain.addPlatformConfiguration` with `PlatformConfigurableToolChain.target(Platform..., Action<ConfigurableToolChain>)`
 * Replace the built-in `TargetPlatformConfiguration` actions with `Action<ConfigurableToolChain>`
 * If `PlatformConfigurableToolChain.target()` is called on a tool chain, then the default target configurations are removed.
+* Documentation describes how to define a new platform.
+* Documentation describes how to configure a tool for an existing platform.
 
 ### User visible changes
 
@@ -1305,6 +1311,56 @@ this consistent with the way that tool arguments are configured in a tool chain.
 * When no Platform architecture/os is defined, assume the current platform architecture/os, not the tool chain default.
     * This will require detecting the current platform, and supplying the correct tool chain arguments when building.
 
+
+## Story: Modify command line arguments for visualCpp toolchain prior execution
+
+provide a 'hook' allowing the build author to control the exact set of arguments passed to a visualcpp toolchain executable.
+This will allow a build author to work around any limitations in Gradle, or incorrect assumptions that Gradle makes.
+
+### Implementation
+
+* Change `VisualCppToolChain` to extend `ExtendableToolChain` and register `linker` and `staticLibArchiver` tools
+* Move registration of cpp, windows-rc and assembler tools in VisualCppToolChain to according plugins
+* Extract `CommandLineToolChain` interface out of `Gcc` and introduce similar functionality to VisualCpp and Clang tool chains.
+* Move setter/getter of executables in into GccCommandLineToolConfiguration
+* Add according documentation to userguide/DSL reference and update release notes
+
+### User visible changes
+    	
+		apply plugin:'cpp'    
+		
+		model {
+            toolChains {
+                visualCpp(VisualCpp) {
+                    cppCompiler.withArguments { args ->
+                            args << "-DFRENCH"
+                    }
+                }
+            }
+        }
+
+
+### Test coverage
+
+* Can tweak arguments for VisualCpp, Gcc and Clang
+
+## Story: Allow configuration of tool chain executables on a per-platform basis (Gcc based toolchains)
+
+### Implementation
+
+* In AbstractGccCompatibleToolChain change initTools method to configure configurableToolChain instead after targetPlatformConfigurationConfiguration is applied 
+
+### Test coverage
+
+* Can use g++ instead of gcc for compiling C sources
+* Can use custom executable
+
+### Open issues
+
+* path configuration is currently not possible on a per platform basis. full paths to executables must be used or executable must be on 
+system path.
+
+
 ## Story: Improved DSL for tool chain configuration
 
 This story improves the DSL for tweaking arguments for a command-line tool that is part of a tool chain, and extends this
@@ -1316,8 +1372,7 @@ ability to all command-line based tool chains. It also permits the configuration
 * Rename `GccTool` to `CommandLineTool` and change to have `withInvocation(Action<CommandLineToolInvocation>)` in place of `withArguments`
 * Remove tool-specific getters from `Gcc`, and instead make `Gcc` serve as a NamedDomainObjectSet of `CommandLineTool` instances.
     * Continue to register a `CommandLineTool` for every supported language.
-* Allow the `eachInvocation` method to override the default executable to use.
-* Extract `CommandLineToolChain` interface out of `Gcc` and introduce similar functionality to VisualCpp and Clang tool chains.
+* Allow the `withInvocation` method to override the default executable to use.
 * Add a sample, user-guide documentation and note the breaking change in the release notes.
 * Consolidate various `ArgsTransformer` implementations so that most/all simply set/modify args on a `CommandLineToolInvocation`.
 
@@ -1354,6 +1409,7 @@ ability to all command-line based tool chains. It also permits the configuration
 
 * Only to register a `CommandLineTool` for languages that are supported by build.
    * Need to make it easy to have centralised tool chain configuration that works regardless of languages in effect.
+* Make it simpler to add support for new languages to existing tool chain implementations
 
 ## Story: Only use gcc/g++ front-ends for GCC tool chain
 
@@ -1421,6 +1477,12 @@ This story also aggregates a bunch of review items that relate to Architecture a
 - How to make Platform instance immutable
 - Consistent API for Architecture and OperatingSystem: either public method on both [os.isWindows(),arch.isAmd64()] or only on internal api.
 - Include ABI in architecture so that the correct prebuilt library can be selected for a tool chain
+- When no Platform architecture/os is defined, assume the current platform architecture/os, not the tool chain default.
+    - This will require detecting the current platform, and supplying the correct tool chain arguments when building.
+    - We can then remove the concept of the "tool chain default" platform, and always explicitly tell the tool chain which platform to build for.
+- For GCC, need to probe the output of the compiler to determine exactly what is being created
+- For Clang, need to provide the full `-target <triple>` to define the exact output, or provide a subset and probe the output.
+    - see http://clang.llvm.org/docs/CrossCompilation.html
 
 ## Story: Include all macro definitions in Visual Studio project configuration
 
@@ -1878,6 +1940,11 @@ TBD
 - Don't create compile tasks for empty source sets
 - Compile windows resource files with gcc/clang using [`windres`](http://sourceware.org/binutils/docs/binutils/windres.html)
 
+### Incremental compile
+
+- Perform incremental compile when header is included via simple macro definition
+- Keep a separate, build-scoped cache of file -> parsed includes. This would prevent need for reparsing per-variant and per-component.
+- Detect changes to headers that are implicit on the include path via the tool chain
 
 ## Target platforms
 
@@ -1913,11 +1980,14 @@ TBD
     - A component packaging that satisfies multiple points in the variant space.
     - Use `lipo` to merge two binaries into a single universal binary.
     - Transforms the meta-data for the component - same set of variants but different set of binaries.
+- Use separate directories for output binaries, rather than encoding all dimensions in the name: eg `flavor/platform/buildType/myLib.so`
 
 ## Toolchains
 
 - DSL to declare that a toolchain supports certain target platform, and how to invoke the tools to do so.
 - Introduce `XCode`, `Cygwin`, `MinGW` toolchains, to allow selection of specific gcc or clang implementations.
+    - Use the `XCode` tool chain to determine mac-specific gcc args
+    - Use the `Cygwin` and `MinGW` toolchains to provide additional path requirements for `InstallExecutable` task
 
     toolchains {
         gcc {
@@ -1936,6 +2006,8 @@ TBD
         }
     }
 
+- Prevent configuration of tool chains after availability has been determined.
+
 ## Structure
 
 - Some common plugin that determines which tool-chains to apply
@@ -1953,6 +2025,11 @@ TBD
 - Need to make standard 'build', 'check' lifecycle tasks available too. The `assemble` task should build all buildable variants.
     - Reasonable behaviour when nothing is buildable on the current machine.
 - Come up with consistent naming scheme for language plugins: 'cpp', 'c', 'assembler', 'java-lang', 'scala-lang', etc
+- Windows resources
+    - Automatically add `/noentry` and `/machine` linker args when building resource-only DLL
+    - Actually inspect the binary to determine if there are any exported symbols
+    - Use a model rule to determine if library sources contain windows resources
+
 
 ### Performance
 
@@ -1967,8 +2044,16 @@ TBD
 - Better way to see how the compiler is being invoked
 - Make names less important
 
+## Test coverage
+
+- Update the UnknownOS CI build to run on java 7, and remove the "CAN_INSTALL_EXECUTABLE" test requirement
+- Integration test coverage for 64-bit assembler on all platforms/tool chains.
+- Verify that the correct windows system libraries are available at link time
+    - Use a test app that uses something like WriteFile() to write its hello world message to stdout. If it can link and run, then the paths are probably ok.
+
 # Open issues
 
+* For incremental build with visual c++, use `dumpbin  /RAWDATA` to strip timestamps from binary files before comparison
 * Add ABI as an aspect of target platform.
 * Output of any custom post link task should be treated as input to anything that depends on the binary.
 * Route stdout to info level when linking a shared library using visual studio, to get rid of the pointless notice.
@@ -2003,3 +2088,6 @@ TBD
 * JNI plugin generates native header, and sets up the JNI stuff in $java.home as a platform library.
 * Model minimum OS version.
     * For OS X can use -mmacosx-version-min option.
+* Clean task for a binary
+* Update CDT support to match Visual Studio support
+* Rename 'install' task to indicate that it's installing a developer image