This message was deleted.

Thank you for sharing the internal notes 🙇

the person that spent two years putting in bazel was ultimately fired. we are slowly trying to divorce bazel. at least two cost reasons (developers waiting for unchanged libraries to rebuild, and rebuilding twice on Circle) and general notion that it forced us to "re-bazel" manually anytime we wanted to accept a c++ library update. Founders now agree it was a really bad idea.

What exactly limits usage of Gradle 6.0.1 on Apple M1 machines?

Sadly, that answer appears to be outside my 90 day window of Slack search. I was told that C++ (maybe everything) would not acknowledge platform parameters for M1 and build. I therefore abandoned that line of thought and focused upon 8.x upgrade.

Then how it was possible that Bazel was overcoming it while Gradle wasn’t? It sounds like problem was with gcc not with Gradle 🤔 Sorry, if I am spitting some nonsense, just trying to understand.

ok, again vague memory, gradle code for C++ builds was not picking the needed compiler for M1 ... I saw @Vampire typing ... I think he gave the true answer then.

No, just writing up some notes, no idea about macOS or native development

... so sad. such a build-up, then nothing. 😄

Maybe you got me wrong. I'm writing up some notes for you, not for me, so I wouldn't say "nothing". 😄

appreciated. I am long, long way from gradle expert.

Thank you Matthew, for the discussion 🙂

Some notes:

Sadly, that answer appears to be outside my 90 day window of Slack search.

https://www.linen.dev/s/gradle-community has all the history searchable

Once the simple sounding syntax changes were made, nothing worked.

Yeah, if it advices to use

implementation

, that is unlucky if the build does not properly declare its dependencies, but depends on transitive libraries being present. I can recommend the https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin plugin that helps you keeping your dependencies in order. For a quick migration without cleaning up the unlucky bad practice, just using

api

as replacement would have been better and then maybe cleaning it up, for example with the mentioned plugin.

The “implementation” dependency will NOT appear on the compile or the runtime classpaths of other subprojects.

That's just plainly wrong. Well, half-wrong. Yes, it will not be on the compile classpath, that is intended, as it makes for a cleaner design, declaring your dependencies where needed and most importantly greatly decreases compilation speed by smaller compile class paths by not polluting downstream projects unnecessarily. But of course the

implementation

dependencies will be on the runtime classpath of downstream projects. The project needs them at runtime, so they will be present. If you need something at compile time, but not at runtime, like nullability annotations or similar, then it goes to

compileOnly

(or

compileOnlyApi

if also downstream projects need them to compile but still not at runtime), becuase those are indeed not part of the runtime classpath.

.pom files only include “implementation” and “runtimeOnly” dependencies. An “api” dependency is not included.

That's also just wrong, unless you manually manipulate the pom file to have that result

Therefore sometimes a subproject has the dependency listed twice: once as api so other subprojects have visibility and second as implementation to list dependency in pom.

If you really have / need that, something is really f**** up in your build, that is not normal at all and I have never seen such behavior. And I use Gradle since pre-1.0

Warning: there is a high chance of confusion. gradle has two completely different objects/concepts: testFixture without “s” ending and testFixtures with “s”. And they both apply to java tests, though in completely different manner.

Please don't blame Gradle. "testFixture" is not a thing in Gradle per-se unless you apply some plugin adding such a thing or adding it yourself. Gradle built-in only "testFixtures" exists.

I have reviewed your reply and find there is no way I can argue any point since I know I lack some essential technical knowledge in this case. I thank you for the detail. That was the hoped for outcome of publishing those notes. Again thank you @Vampire

Always a pleasure 🙂

I have added your notes to our internal document.

Maybe replace "f**** up" by "messed up" then 😄

replacement done.

🤷‍♂️

@Vampire: I believe my api versus implementation notes to be accurate, especially after some follow-on testing ... BUT, there are two non-standard factors in my tests: • we are using old "maven" plugin, not "maven-publish" ... ("maven-publish" is my next task) • we have legacy code (8 years old) that edits the .pom and changes all "release" scope items to "compile" I expect that our world will match your world once I finish migrating to "maven-publish" plugin, and eliminate our pom editing code.

I would really wonder if that's the case. I'd usually ask for an MVCE, but if it is really the maven plugin, that's probably not worth, as it does not exist anymore anyway. But if you see similar behavior with maven-publish, you should probably create one.

Going for closure on this topic. Yes, some of the pom problem was self induced. We had code that removed any pom entry that was not scoped as "compile". Therefore did not see that implementation dependencies are scoped as "runtime" and api dependencies are scoped as "compile". The dependency is scoped as "compile" when both implementation and api exist.