jdigger / gradle-defaults Goto Github PK

There should be an option to keep it enabled, but the standard linting it does is cray-cray.

It would be easier to use pieces of this independently if they were plugins following the standard Gradle models.

If the 'java' plugin is applied:

sourceCompatibility = compatibilityVersion
targetCompatibility = compatibilityVersion

need details on what that involves

Only if there are .java files in src/test

If you set them on the root project, children projects don't receive the value automatically.

Even if lombok.enabled = true it will create a config for annotation processing, but it won't properly configure it without the 'java' plugin being applied.

https://github.com/TWCable/grabbit-cli/blob/54703d4/gradle/quality.gradle

https://github.com/TWCable/grabbit-cli/tree/54703d4/gradle/config

We are seeing a bug in gradle-git 1.3.2 where the inferred version does not update to the latest tag. This is reproduceable by all repo users.
For example, we have released version 1.14.0, local repos are updated to latest master, and the inferred version for future builds remains at 1.13.1-dev instead of 1.14.1-dev

Unfortunately we do not know yet how it ended up in this corrupted state or an easy fix. Deleting the release/tag and re-releasing 1.14.0 does not seem to fix the issue.

For now we are working around it but wanted to make you aware 😃

• Check that the root of the project contains a LICENSE file
• Check that a LICENSE_HEADER file exists in the gradle dir
• Make sure that the binTray and license plugins use the same information
• Allow the use of a "common name" (e.g., "APACHE-2") to specify the license information
  • That should auto-populate the LICENSE.txt and LICENSE_HEADER files
  • For a list of some of the more common licenses, see license-maven-plugin templates
  • Allow for PROPRIETARY for non-opensourced materials
  • If openSource = false disable this plugin or assume PROPRIETARY
• If any of those checks fails, fail and offer help
• Put a copy of the LICENSE file into META-INF

Right now you still need to do at least:

buildscript {
    ext.kotlin_version = '1.0.6'
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}
apply plugin: 'com.mooregreatsoftware.kotlin'

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}

to have a functioning build.

Make applying "com.mooregreatsoftware.kotlin" automatically:

• set the buildscript block
• register the plugin
• set up dokka
• add the stdlib to the classpath
• ...

Specifically, it currently formats like:

try {
    // code
}
catch (Exception exp) {
    // code
} finally {
    // code
}

So finally should be on it's own line as well.

https://github.com/danthegoodman/gradle-capsule-plugin

See for example https://github.com/TWCable/grabbit-cli/blob/54703d4/build.gradle#L116-L152

@jdigger Very minor issue with an easy fix on the project config side. Wanted to check what the intention is before I made a pull request to change it. When you run gradlew properties to view the project environment properties for example, it fails if orgId is not set.

Execution failed for task ':properties'.

"orgId" is not set for "defaults" on project

Right now it defaults to warn but a project should be able to make violations count as errors.

testCompile "org.spockframework:spock-core:1.0-groovy-2.4", {
    exclude group: 'org.codehaus.groovy', module: 'groovy-all'
    exclude group: 'org.hamcrest', module: 'hamcrest-core'
}

There is a gotcha with the Groovy version...

If the project doesn't already have Groovy, add it as a testCompile. Otherwise use the version of Groovy the project already has.

Allow a way to specify the version of the bintray plugin to use.

See http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#askipuses

This allows the use of 3rd party libraries without having to go annotation crazy or having to annotate the libraries yourself.

For some projects that use a specific artifact repository (such as in-house projects), it may not be appropriate to go out to jcenter.

Something along the lines of

def gitConfig = new org.eclipse.jgit.storage.file.FileRepositoryBuilder().findGitDir().build().config
def userEmail = gitConfig.getString('user', null, 'email')

jar {
    manifest {
        attributes 'Implementation-Title': description,
            'Implementation-Version': version,
            'Built-By': userEmail ?: '[email protected]',
            'Built-Date': new Date(),
            'Built-JDK': System.getProperty('java.version') ?: '1.7',
            'Built-Gradle': gradle.gradleVersion
    }
}

Unless -Prelease.stage is specified, publishing to the local maven repository should assume -SNAPSHOT