Gradle 2.4-rc-1 is now available for testing

(Luke Daley) #1

The Gradle team is pleased to announce the availability of the first release candidate for Gradle 2.4. This release contains many new features and significant performance enhancements pertinent to all builds.

Please read the release notes for more information. Downloads and wrapper usage instructions are available from gradle.org/release-candidate. Please try Gradle 2.4-rc-1 with your projects and report any problems.

1 Like
(Luke Daley) #7

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

(Jörn Huxhorn) #8

Everything fine with my usual three projects.

It’s actually not just fine but awesome - the speedup is tremendous! :heart_eyes:

One of the builds failed initially because of a codenarc violation that wasn’t reported in Gradle 2.3. It seems like it didn’t check the test sourcesets before but is doing so now. Either that or the codenarc rulesets changed.

This isn’t a problem of Gradle 2.4, though. I just wanted to mention it for the sake of completeness.

(Sterling Greene) #9

Do you know which rule violation you were seeing? CodeNarc only changed versions, so if it’s doing something new, we’d like to include that as a warning in the release notes.

(Bernát Gábor) #10

No issues seen so far :slight_smile:

(Jörn Huxhorn) #11

The “NoDef” rule complained about our Spock specifications.
While that rule makes sense for application code it’s not really applicable to test code.

Our codenarc.xml looked like this:

<ruleset xmlns="http://codenarc.org/ruleset/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://codenarc.org/ruleset/1.0 http://codenarc.org/ruleset-schema.xsd" xsi:noNamespaceSchemaLocation="http://codenarc.org/ruleset-schema.xsd">
    <ruleset-ref path="rulesets/basic.xml"/>
    <ruleset-ref path="rulesets/convention.xml">
        <exclude name="CouldBeElvis"/>
    </ruleset-ref>
    <ruleset-ref path="rulesets/imports.xml">
        <exclude name="NoWildcardImports"/>
    </ruleset-ref>
    <ruleset-ref path="rulesets/naming.xml">
        <rule-config name="MethodName">
            <property name="regex" value="^[a-z][\$_a-zA-Z0-9]*$|^.*\s.*$"/>
        </rule-config>
        <exclude name="ConfusingMethodName"/>
        <exclude name="FactoryMethodName"/>
    </ruleset-ref>
    <ruleset-ref path="rulesets/logging.xml"/>
</ruleset>

We just excluded the rule in question for now:

<ruleset-ref path="rulesets/convention.xml">
    <exclude name="CouldBeElvis"/>
    <exclude name="NoDef"/>
</ruleset-ref>

We should probably use different rules for src/main and src/test in the long run…

(Sterling Greene) split this topic #12

I moved 7 posts to a new topic: 2.4-rc-1 Regression: JNA path conflicts in test execution JVM

(Scott Palmer) #13

I realize it is incubating, but I’ve discovered something in the configuration of my native C++ project:

I’m trying to do most of the configuration in a custom plugin/script and then have the ability to tweak options in the project build.gradle file. This was working with 2.3, but with 2.4-rc-1 gradle thinks I’m trying to re-declare my main library instead of just tweak some options on it.

Exception thrown while executing model rule: model.components
Cannot create ‘components.main’ using creation rule ‘model.components > create(main)’ as the rule ‘model.components > create(main)’ is already registered to create this model element.

The line it is complaining about is in a method of my plugin that is used to tweak the source folders:

    public void withCppSource(def closure) {
        project.model {
            components {
                main(NativeLibrarySpec) {
                    sources {
                        cpp {
                            source closure
                        }
                    }
                }
            }
        }
    }

I’m providing this utility method so my plugin keeps my main build.gradle file compatible with Gradle 2.2.1 and later versions (2.3+) where the structure of native C++ scripts has changed.

Looking closer at the release notes, I suspect this is not surprising behaviour (the notes state: “Using create syntax fails when the element already exists.”) . But I’m not sure how to fix my code to accommodate the delayed creation and still have a utility method to configure the C++ source files. What syntax should I be using?
Everything I’ve tried has failed with the message:
The following model rules are unbound:
model.main.sources.cpp
Mutable:
- main.sources.cpp (java.lang.Object)

(for main.sources, main.sources.cpp, main.sources.cpp.source ,etc.)
Which I think is related to the other note: “There are currently no query method on this interface.”

Gradle 2.4-rc-2 is now available for testing
(Gary Hale) #14

Have you tried just leaving off the type?

        project.model {
            components {
                main {
                    sources {
                        cpp {
                            source closure
                        }
                    }
                }
            }
        }
(Luke Daley) #15

This topic is no longer a banner. It will no longer appear at the top of every page.

(Igor Popov) #16

Hi,

I just wanted to point out a small mistake (spelling) in the release notes:
https://gradle.org/docs/2.4-rc-1/release-notes

It’s in the code sample for the “Depending on a particular Maven snapshot version” section:
depenencies should actually be dependencies (missing “d”).

(Luke Daley) #17

Many thanks. I’ve made the change for the next RC or final release.