trevjonez / composer-gradle-plugin

Gradle task type and plugin for interacting with https://github.com/gojuno/composer
Apache License 2.0
54 stars 18 forks source link

Unable to create custom tast #52

Closed emartynov closed 4 years ago

emartynov commented 4 years ago

Setup:

buildscript {
  dependencies {
    classpath gradlePlugins.composerPlugin
  }
}

apply plugin: 'com.trevjonez.composer'

import com.trevjonez.composer.ComposerTask
task customTask(type: ComposerTask, dependsOn: ['assembleDebug', 'assembleDebugAndroidTest']) {
...
}

I'm getting:

unable to resolve class com.trevjonez.composer.ComposerTask
   @ line 21, column 1.
     import com.trevjonez.composer.ComposerTask
trevjonez commented 4 years ago

as far as I can tell it all looks correct. I suspect the dynamic nature of groovy build scripts and groovy/gradle class loading is to blame here.

is the above code pulled in via apply from:? I've never had good luck with that route.

if you have a buildSrc project in place already to get your gradlePlugins.composerPlugin working, you might try adding the composer plugin to the api dependency configuration of the buildSrc project so that the entire build has the classes available. I've always had a much better experience in android studio when they are on the class path like that rather than through the dynamic gradle loading mechanism of the main build since it makes jump to source and the open class actions work as expected.

emartynov commented 4 years ago

So the plugin declaration is in root build.gradle.

The composer related code is in the separate gradle file that is applied in the app module gradle file.

trevjonez commented 4 years ago

I am fairly certain this is an issue with the gradle config then not this project. let me ask around and see if I can find some guidance on how to best resolve.

dannybduval commented 4 years ago

Just curious why you'd have it going this way, testDebugComposer is going to be reliant on those tasks to start with. The plug-in is saying that it is reliant on getApk and getTestApk

trevjonez commented 4 years ago

when you apply the composer plugin it registers hooks with the plugin manager looking for either the android library or app plugin and then adds configuration extension and apply's specialized plugins for the project use context that then registers tasks and handles remaining configuration. The plugin also registers an after evaluate hook that verifies that either it was applied to an android app/lib project OR if a custom task was registered on the project.

End result is ensuring the plugin is doing basic sanity checks whenever applied to a project.

in the case of doing the custom task here, on a non android project there will be no testDebugComposer task. this could be useful if you have one CI step building APK's then distributing pre built apk's to just invoke them. although at that point you just as well use composer directly since you end up having to specify nearly every param manually.

emartynov commented 4 years ago

The issue is not urgent now. I managed to achieve what I needed with the gradle property. We have UI offline tests (integration) and much less online (e2e) tests. All run on the debug build. I needed a way to provide different runner arguments based I want to run first type or second type of tests.

trevjonez commented 4 years ago

Good thinking using project properties. I am going to close this as it seems you found a solution for your original goal. Additionally I still don't know that there is anything directly actionable here for the plugin.

If it comes up again maybe we can figure out a way to write a test for this. (may be hard as test kit basically requires plugins block application for that)