Understanding the underlying gradle magic - back to basics

[Learner]

@"sterling

The .gradle file is Groovy with a couple of ASTs on top of it …

Yes, that much I knew. It is the exact “ASTs on top of it” that escape me.

@"sterling

I’m not sure why you’re doing this. Why is a dependency changing the dependent project?

Working around Eclipse classpath model deficiencies. You can see some details in my other question post here: https://discuss.gradle.org/t/main-vs-test-compile-vs-runtime-classpaths-in-eclipse-once-and-for-all-how/17403
In short, we maintain having in-project “main” and “test” source sets outside Eclipse. However, when we detect that Eclipse-related tasks (such as eclipseClasspath) are executed we declare additional projects for each exiting Java project. If a project is named we dynamically create a project .test. These are local only (not in source repo) and are otherwise ignored by gradle builds. Their Eclipse configuration is set from the “parent” (main) project - source location, test classpath, etc.

@"sterling

Yes, the built-in source set main doesn’t follow that convention. I don’t know the history, but it either predated that convention or it was considered worth the inconsistency for the 99% case.

Thank you!

@"sterling

Configurations, FileCollections and other Buildable things have information about which task produces them. When you have a project dependency, Gradle uses the default configuration which has artifacts registered to it. For a Java project, the jar file is registered as an artifact produced by the jar task. The jar task knows that it archives sourceSets.main.output, which is produced by the processResources and compileJava tasks. That information is used when building the task execution DAG.

The correct execution order is a product of the dependency information and the DAG.

Thank you! I suspected there is something about this but never had officially found it.

@"sterling

My suspicion is that your mainProduct configuration only knows about the particular jar file and not the task that produced it.

Thank you! That must be it. I explicitly set the file because I believed that i what was needed, hence cutting the branch I was sitting on.

@"sterling

There are a lot of samples that come in the Gradle distribution that may help and there are some free resources. Udacity course, while made for Android users, covers some Gradle basics and is free.

Thanks! Will have a look.