Closed Larusso closed 4 years ago
Yeah, a lot of pain has come out of the publish task. Currently, if you apply GPP last, it should rename the publish task to gppPublish
. I've debated how this should work before, but couldn't make up my mind. So is your vote in favor of making GPP add its dependencies to the publish
task? I've thought that might be unexpected if people are used to that task only doing maven things.
I know it's a tough topic. I personally prefer one publish
task that acts as the lifecycle task just like assemble
. I think that the whole topic like most of gradles internal plugins is slightly to much opinionated around java.
Yes the publish plugin from gradle drags other stuff into the build that maybe not all users are happy about. I will rethink this as well. I used the publish plugin before it had the new publications setup etc.
What I essential want is a high level tasks that does the default behavior when envoked. If I call build
the project assembles and gets tested. If I call publish
I want that too plus the publication step to whereever the build configured it. The specialized publish task are there for finer control. When you use gradle locally. I try to setup my CI scripts as stupid as possible. They don't know that the project is an android build or a java application or whatever. I come from this angle. But again I can understand your standpoint.
But in gradle terms the cleanes solution would be to implement publications as gradle defined them. https://docs.gradle.org/current/userguide/publishing_customization.html
I never implemented it like this for my plugins because of the nature how gradle introduces such API's. Incubation -> maybe stable -> 2 versions later gone or stable. But it seems this API is in for good and the Android plugin itself can also publish aars with it.
Last question. Do you create the gppPublish
in any case? I could work with this solution if you don't want to bind your plugin to the publish plugin or decide against using the publish
task as your main entry task.
Thanks for elaborating! I think adding GPP's dependencies to an existing publish
task is a reasonable change for the upcoming v3.0 release I'm working on.
Describe the bug
The plugin adds a
publish
task to the gradle task list. Many other plugins also do this but don't provide their own custom implementation. Instead they leverage the gradle lifecycle task calledpublish
and add their task(s) as a dependency. Just likeassemble
andcheck
.The problem I have is that I use another plugin which also hooks into the
publish
task. And in combination with thegradle-play-publisher
this results in errors or weird behavior.How To Reproduce
Create a android project and follow the
gradle-play-publisher
setup steps. Also add a second publish plugin likenet.wooga.appcenter
classpath 'gradle.plugin.net.wooga.gradle:atlas-appcenter:0.7.1'
apply plugin: 'net.wooga.appcenter'
Versions
Tasks executed
publish
Expected behavior
That all tasks, depending on
publish
will be executed. In my example publish to play and publish to appCenterAdditional context (if a crash, provide stack trace)
Depending on the order which plugin gets applied when, I see two different errors. If I apply
gradle-play-publisher
before theappCenter
plugin, the build crashes:If I apply the
appCenter
before aftergradle-play-publisher
then thepublish
task won't call thegradle-play-publisher
publish steps. I did a small workaroundAll in all I see two major issues. I plugin should not setup a task with a name that is a known lifecycle task name in the gradle echosystem. Rather that creating a
publish
task the plugin should use the one provided by the gradle publish plugin. And bind the default logic to it as a dependency. This also makes sure that the ordering of plugins doesn't matter.