This message was deleted.

I doubt there are any "good examples", because whenever you need a "complete set", you have problems as you never know whether your some pluign applied after yours does more work or whether the build script does more work after your plugin was applied, or whether the evil

afterEvaluate

block of a build script or another plugin is executed after an

afterEvaluate

you register and does add there. A complete picture is generally just available after configuration phase has finished, so you cannot do additional configuration based on it. Maybe if you elaborate on your use-case someone can suggest a different approach of how to achieve what you need.

Right, I get that. I was looking for something like

SourceSetContainer#all

Can't you just use the

classesDirs

or

output

of the

SourceSet

or similar and not care about actual `SourceDirectorySet`s?

Its the same problem no? Things after me could add new ones

You said you have a task for bytecode enhancement. So when the task executes, there should not be anything added anymore

It ties in with a question I was asking yesterday about bytecode enhancement and up-to-date. if I do the enhancement in place it messes up up-to-date checks. So I had the thought to offer the user an option to enhance in place or to a distinct directory. In that second case, I was worried about mimicing the classes dir structure. But maybe I am just overthinking this

Why should you care to maintain the classes dir structure? Gradle produces the class files in different directories, as tasks should not have overlapping outputs. But if you have one task that takes the classes of the other tasks and does a bytecode enhancement on them, I'd say it is perfectly fine to have them land in one output directory per source set.

I'd say it is perfectly fine to have them land in one output directory per source set.

That's probably reasonable as well

As I said, I'm not sure to whom you are trying to be nice, and what benefit they have. 🙂 That it lands in different directories is a pure technical necessity to not have overlapping output directories. In former days, long ago, Groovy and Java compile tasks compiled into the same output directory. It was just found to be problematic with things like up-to-date checks and task output caching, so it was split to have dedicated output directories per task.

Sure, I get that. Like I said, I planned on allowing the choice between in-place enhancement and enhancing to a separate dir. I was just trying to have the same logic to write out the enhanced classes based on a base dir

Always a good choice 😄

Anyway, I am playing around compile.doLast (based on the other discussion) to see if that helps with the up-to-date stuff and just always do in-place. That would by far be the best outcome

up-to-date should work fine with that. Incremental might become a problem maybe, not sure.

incremental as in

@Incremental?

Yeah that would be a shame, but pick poison it sounds like

Always a pleasure 🙂