New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support automatic detection of Kotlin-based builds #37

Closed
cbeams opened this Issue May 30, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@cbeams
Contributor

cbeams commented May 30, 2016

To use Kotlin build scripts, one has to set an explicit buildFileName in his settings.gradle file:

def configureGradleScriptKotlinOn(ProjectDescriptor project) {
    if(project.file('build.gradle.kts').exists()) {
        project.buildFileName = 'build.gradle.kts'
    }
    project.children.each { configureGradleScriptKotlinOn(it) }
}

include 'a', 'b', 'c'

configureGradleScriptKotlinOn rootProject

The default value of buildFileName is build.gradle.

This issue is about removing the need to set an explicit buildFileName.

See also #56 for settings.gradle.kts support.

@cbeams cbeams added this to the 1.0.0-M2 milestone May 30, 2016

@cbeams cbeams modified the milestones: 1.0 M3, 1.0 M2 Jun 13, 2016

@bamboo bamboo modified the milestones: 0.3.0, 1.0.0 Jul 6, 2016

@bamboo bamboo modified the milestones: 1.1.0, 1.0.0 Feb 23, 2017

@bamboo bamboo modified the milestones: 0.9.0, 1.1.0 Mar 6, 2017

@eskatos eskatos self-assigned this Apr 18, 2017

@eskatos

This comment has been minimized.

Show comment
Hide comment
@eskatos

eskatos Apr 27, 2017

Member

In order to support automatic detection of Kotlin build scripts and settings scripts Gradle will need to get the supported file extensions as early as in its launcher and tooling-api provider connection.

The earliest usage is resolving the root directory of a build. The build layout depend on, among other things, the location of the settings script. Gradle needs the supported file extensions in order to resolve the settings script location.

The current SPI, ScriptPluginFactoryProvider, is too heavyweight and require management such as dependency injection. This is unsuitable. We need to introduce a new Gradle SPI that can be used very early and doesn't require any management.

/**
 * Scripting language provider SPI.
 */
public interface ScriptLanguage {
    /**
     * Returns the file extension for scripts written in this script language.
     */
    String getExtension();
    /**
     * Returns the fully qualified class name of the {@link ScriptPluginFactoryProvider}
     * for this script language.
     *
     * Implementations can benefit from injection using {@link javax.inject.Inject}.
     */
    String getProvider();
}

Gradle will then use getExtension() to resolve settings scripts and build scripts files when bootstrapping a build and getProvider() to load the heavyweight script language support later, when needed.

Member

eskatos commented Apr 27, 2017

In order to support automatic detection of Kotlin build scripts and settings scripts Gradle will need to get the supported file extensions as early as in its launcher and tooling-api provider connection.

The earliest usage is resolving the root directory of a build. The build layout depend on, among other things, the location of the settings script. Gradle needs the supported file extensions in order to resolve the settings script location.

The current SPI, ScriptPluginFactoryProvider, is too heavyweight and require management such as dependency injection. This is unsuitable. We need to introduce a new Gradle SPI that can be used very early and doesn't require any management.

/**
 * Scripting language provider SPI.
 */
public interface ScriptLanguage {
    /**
     * Returns the file extension for scripts written in this script language.
     */
    String getExtension();
    /**
     * Returns the fully qualified class name of the {@link ScriptPluginFactoryProvider}
     * for this script language.
     *
     * Implementations can benefit from injection using {@link javax.inject.Inject}.
     */
    String getProvider();
}

Gradle will then use getExtension() to resolve settings scripts and build scripts files when bootstrapping a build and getProvider() to load the heavyweight script language support later, when needed.

eskatos added a commit to gradle/gradle that referenced this issue Apr 27, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 27, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 27, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 27, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

@eskatos eskatos referenced this issue Apr 28, 2017

Merged

Introduce ScriptingLanguage SPI #1908

5 of 5 tasks complete
@eskatos

This comment has been minimized.

Show comment
Hide comment
@eskatos

eskatos Apr 28, 2017

Member

@bamboo the first PR against Gradle is ready for review gradle/gradle#1908

Branches for all steps against Gradle are pushed:
image

If you could have a look at the whole chain of changes it would be awesome.

Member

eskatos commented Apr 28, 2017

@bamboo the first PR against Gradle is ready for review gradle/gradle#1908

Branches for all steps against Gradle are pushed:
image

If you could have a look at the whole chain of changes it would be awesome.

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

@bamboo bamboo self-assigned this Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

eskatos added a commit to gradle/gradle that referenced this issue Apr 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment