Skip to content
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

Add meta tasks for Android variants #183

Merged
merged 5 commits into from
Dec 12, 2018

Conversation

Tapchicoma
Copy link
Collaborator

This PR adds android variants meta tasks, that trigger tasks for all source sets in given variant.

For example running ktlintKellerbierDebugCheck meta task triggers following tasks:

$ ./gradlew :samples:android-app:ktlintKellerbierDebugCheck -m

:samples:android-app:ktlintDebugSourceSetCheck SKIPPED
:samples:android-app:ktlintKellerbierDebugSourceSetCheck SKIPPED
:samples:android-app:ktlintKellerbierSourceSetCheck SKIPPED
:samples:android-app:ktlintMainSourceSetCheck SKIPPED
:samples:android-app:ktlintKellerbierDebugCheck SKIPPED

Also added limited support for android projects in new Kotlin multiplatform plugin:

$ ./gradlew -m :samples:kotlin-mpp-android:ktlintKellerbierDebugAndroidLibCheck

:samples:kotlin-mpp-android:ktlintAndroidLibDebugSourceSetCheck SKIPPED
:samples:kotlin-mpp-android:ktlintAndroidLibKellerbierDebugSourceSetCheck SKIPPED
:samples:kotlin-mpp-android:ktlintAndroidLibKellerbierSourceSetCheck SKIPPED
:samples:kotlin-mpp-android:ktlintAndroidLibMainSourceSetCheck SKIPPED
:samples:kotlin-mpp-android:ktlintKellerbierDebugAndroidLibCheck SKIPPED

Currently variant task name is inconsistent with source sets tasks names, but that will be addressed in #182 issue.

Closes #170.

Now plugin adds variant specific tasks that depends on variant
sourceSets check tasks.

Signed-off-by: Yahor Berdnikau <egorr.berd@gmail.com>
Signed-off-by: Yahor Berdnikau <egorr.berd@gmail.com>
Signed-off-by: Yahor Berdnikau <egorr.berd@gmail.com>
@Tapchicoma
Copy link
Collaborator Author

@tasomaniac may you also take a look on this PR?

Copy link
Contributor

@tasomaniac tasomaniac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Only have a small comment. Would be good to add tests for this. Should we craete an issue and link here?

@@ -7,7 +7,10 @@ and this project adheres to [Semantic Versioning](http://semver.org/).

## [Unreleased]
### Added
- ?
- Meta tasks to run check or format on all sources in android variant. (#170)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👌

multiplatformTargetName: String? = null
): Task {
val taskName = "ktlint${variantName.capitalize()}${multiplatformTargetName?.capitalize() ?: ""}Check"
return tasks.findByName(taskName) ?: task(taskName).apply {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead can you use tasks.maybeCreate() that conditionally creates a task and returns the already available task if so.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, all of these options are eagerly evaluated. I'd love if there was a way to lazily instantiate this task.

Don't worry about that though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure actually. findByName is also not lazy. maybeCreate looks like a drop-in replacement of what you do here.

At the end it is not crucial. Either is fine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, this can addressed in next PR with task configuration avoidance. For now, I changed it to maybeCreate()

private fun setCheckTaskDependsOnKtlintCheckTask(project: Project, ktlintCheck: Task) {
project.tasks.findByName("check")?.dependsOn(ktlintCheck)
}

/*
* Helper functions used until Gradle Script Kotlin solidifies it's plugin API.
*/

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a line of documentation for all lower lines, so this newline gap was intentional.

@JLLeitschuh
Copy link
Owner

One concern I want to bring up is the potential for accidental task name collisions.
Are there any cases that anyone can think of whereby declaring source sets in certain ways you could unintentionally get task name declaration collisions?

If there are, please figure out how to prevent these task name collisions.

@tasomaniac
Copy link
Contributor

I don't see any problems. It will bring back the old functionality of the tasks back.

The breaking change would be that the type of the tasks has changed together with the report file destinations. We are using that actually but I will make the necessary changes to support the new structure. I guess the meta task wording in the changelog already captures this.

Signed-off-by: Yahor Berdnikau <egorr.berd@gmail.com>
Signed-off-by: Yahor Berdnikau <egorr.berd@gmail.com>
@Tapchicoma
Copy link
Collaborator Author

One concern I want to bring up is the potential for accidental task name collisions.
Are there any cases that anyone can think of whereby declaring source sets in certain ways you could unintentionally get task name declaration collisions?

I agree with @tasomaniac that there is no problem with this.

@JLLeitschuh
Copy link
Owner

Okay, if you are both unconcerned, then go for it if this is ready to go.

@Tapchicoma Tapchicoma merged commit dc5aa45 into JLLeitschuh:master Dec 12, 2018
@Tapchicoma Tapchicoma deleted the build-types-meta-tasks branch December 12, 2018 21:10
@tasomaniac
Copy link
Contributor

Nice. Are you guys going to release a new version now or does it need more stuff in?

@Tapchicoma
Copy link
Collaborator Author

@tasomaniac As next release will anyway break api - I also want to bump minimal supported Gradle version to 5.0.0 and add task configuration avoidance. Then we can do new 7.0.0 release.

@tasomaniac
Copy link
Contributor

Hey about the task configuration avoidance: there is a way to make it available in a backward compatible way. I found this example from official docs: https://github.com/melix/jmh-gradle-plugin/blob/a034aa88805b7a06fa9c5a825d573554b2aa23e2/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy#L289-L296

Especially with Kotlin extension functions, this can be done in a very nice way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants