[Feature request] Support deliver jar

[cnevinc]

For components like annotation processing (e.g. #1111), we need to deliver jar instead of aar.
Thank you!

┆Issue is synchronized with this Jira Task

[csadilek]

This was also needed recently for: #4618

[pocmo]

We also want to ship a gradle plugin in some cases. I assume that happens as jar too.

[mdboom]

Do we have an ETA on this? This would be helpful as a way to deploy the Glean gradle plugin and fix the various problems that currently exist due to the use of a script instead of a plugin.

[mdboom]

Can you elaborate more on what is needed for this? publishToMavenLocal produces the artifacts for jars already. Is there something downstream of that that needs to be improved?

[mdboom]

Where do the scripts that publish artifacts live (where we would need to extend the .aar handling to include .jars?) The Gradle config itself seems to be working correctly, but I assume there is some other step that pushes these out to the world that needs to be updated?

[pocmo]

CC: @JohanLorenzo

[JohanLorenzo]

Dumping the conversation @pocmo, @MihaiTabara and I had a couple of weeks ago :

sebastian 14:19 UTC - @jlorenzo @mtabara How complicated would it be to extend our AC publishing automation to support JARs too?

jlorenzo 14:20 UTC - how are these jars generated?

sebastian 14:20 UTC - Via gradle too. In this case some modules would create a jar build artifact instead of an AAR.

jlorenzo 14:23 UTC - okay, so on the taskgraph side, we need to expose a new flag like this one

android-components/.buildconfig.yml

Line 6 in 8b955ae

publish: true

, and then taskgraph has to know what to do with it. it's doable, and easily testable

mtabara 14:24 UTC - from beetmover side, it shouldn’t need anything I think. it’s all declarative-artifacts in-tree generated so as long as taskgraph computes the proper payload in transforms, it should just work

jlorenzo 14:26 UTC - and from the maven-metadata.xml point of view, nothing should be changed, it just depends on .pom and .jar are explicitly tested https://github.com/mozilla-releng/maven-lambda/blob/cca6eb9c67af6300b821c26a072ff0e3aedd174d/maven_lambda/test/integration/test_integration.py#L19

To answer the comment:

[...] but I assume there is some other step that pushes these out to the world that needs to be updated?

In addition to what was said above, here's what you need to change in the pipeline. On the bright side, things just need to happen in this repo:

1. Change .buildconfig.yml to expose a new flag that says whether the final artifact is a jar or an aar
2. Modify build_config.py to read this new attribute.
3. Move this logic to build_config.py so the extensions list is given based on the flag of buildconfig.yml.

Then, you should get a new release graph that will tell the workers how to deal with this new file format.

If you're interested in knowing more about the release graph and what taskgraph is: I recommend watching this 3-minute-video: https://johanlorenzo.github.io/blog/2019/10/24/taskgraph-is-now-deployed-to-the-biggest-mozilla-mobile-projects.html.

I'm happy to review the patch, @mdboom, if you'd like to handle it. I think it's a good patch to get to know taskgraph. Please let me know what you think 🙂

[mdboom]

Thanks for the pointers, @JohanLorenzo. I'll file a PR and tag you for review...