Now that @ahochheiden has addressed @sergesanspaille's comment, this looks sensible to me.

Is it possible that we should avoid the workaround and just use / everywhere?

Nothing worrying me here, and o.m.f.components.* was definitely not the right home for this feature-related code.

Fine.

This commit message is actively unhelpful: all detail with no motivation. Rewrite it to explain _why_ all of these AI slop choices are being made. Why not make everybody enumerate RUST_TESTS for crates that should be part of rusttests?

OK.

This patch cleans up the unused settings violation from earlier in the stack. I quite like having it be a Post: clean-up, but if needed it can be folded earlier.

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=101676

Re: testing -- this is what the Glean Debug Ping Viewer is for. See https://mozilla.github.io/glean/book/reference/debug/index.html. You can also have Glean do the logging for you without having to set breakpoints, etc. (But your automated tests are better still, and don't require nudging the clock around.)

This looks like I expect -- thanks for reworking it, @gmalekpour, and sorry for the delayed review. (I appreciate the nudge, it's easy to drop things by accident.)

Fine for the gradle.configure bits.

This doesn't require geckoview-reviewers.

I'm fine with this if it unblocks things.

Yes! Very happy to see these top-level Gradle project lints become the source of truth for all of the Android linting.

Great!

This is looking healthy: https://treeherder.mozilla.org/jobs?repo=try&tier=1%2C2%2C3&revision=285367a27940edb8a0501dae54d6637be20d7fc6

How on earth did this ever work?

This is horrific, but it does address the problem today. It's horrific because we want the plugin to be the source of truth, and this adds accommodations for some random Gradle file to be the source of truth. But fixing this can be follow-up, getting green -as builds is worth a lot.

r+ for mobile/.

Done in https://phabricator.services.mozilla.com/D329267.

I want this and am going to land it to unblock https://phabricator.services.mozilla.com/D329267.

Superceded by https://phabricator.services.mozilla.com/D329204.

https://treeherder.mozilla.org/jobs?repo=try&revision=399dbe5f045f3df47b26fb78fa3ac21fc871632f

Please ensure that mots clean is run before this patch lands. See https://mots.readthedocs.io/en/latest/#cleaning-mots-yaml for more information.

Please ensure that mots clean is run before this patch lands. See https://mots.readthedocs.io/en/latest/#cleaning-mots-yaml for more information.

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=97592

Sorry for the long delay. I'm fine with this; it looks better than what we had before. But it feels to me like the end game here is that the nimbus-fml binaries are provided in Maven artifacts so that all of the version resolution, etc, happens once and is done by Gradle. That's not all that easy to arrange _and_ we're rapidly moving to an application-services-in-tree world so please don't spend time making that happen; but at a high level, that's how this probably should be structured. (There are lots of instances of this; I think that aapt2 gets delivered this way in the Android ecosystem, for example.)

https://treeherder.mozilla.org/jobs?repo=try&revision=a489007e2fe790a466520c5443d2934841a32760

Fine by me.