`JarJarFeature.enable` forces the jarJar task to be configured

[SquidDev]

The JarJarFeature provides a method to disable inheriting classes from the main jar.

However, as enable() uses findByPath (rather than named), this means that it's very easily to accidentally cause the jarJar task to be prematurely configured, and in turn causing disableDefaultSources to silently no-op.

For instance, none of the following will work:

jarJar {
  enable()
  disableDefaultSources()
}

dependencies { jarJar(libs.fooBar) } // Causes jarJar to be enabled.
jarJar.disableDefautSources()

This can be worked around by moving jarJar.disableDefautSources() further up the build script. However, it would be nice if either:

• This worked by default OR
• This didn't silently fail.

[lukebemish]

The whole enable/disable system is... wonky in general. The fix here is a bit complicated -- you can't just make it lazy because the other stuff configured on enable only if the task exists must be non-lazy, or at least not in the task's lazy context! (artifacts, etc shouldn't depend on a single task's configuration timing). The issue here is mainly that jarJar is built to be disabl-able and that leads to issues quite quickly. Best bet is probably to do a quick tasks.named(...), set the enabled of the task in the closure, and surround it in a try-catch for the case that the task doesn't exist? And then set all the runtimeElements stuff, etc outside that context. Or just leave out the try-catch and assume createTaskAndConfiguration will always have been run before enable or disable -- which may be a safe assumption.

[SquidDev]

Is disabling something we know is actually in use anywhere? Doing a GitHub code search doesn't show anything obvious, but that's definitely not an exhaustive check.

That said, I do find myself a little confused by the current disabling logic — why is there a separate enabled and disabled flag? Why does disable() accept a boolean argument, given disable(false) doesn't appear to anything useful?

Best bet is probably to do a quick tasks.named(...), set the enabled of the task in the closure, and surround it in a try-catch for the case that the task doesn't exist?

One solution would be to have properties for the enabled and disableDefaultSources flags, mark those as finalized on read, and then use both of those inside the default task configuration. This should allow lazy configuration (as you don't need to reconfigure the task inside enable) and prevent the silent failures you see now.

The configuration of artifacts would need to remain as-is for now.

[lukebemish]

Disabling is a feature users of NG could use. That's the only reason it exists. And it's silly, there's really no use case for it

[lukebemish]

For enabled vs disabled... Uh. Well. Basically enabled is what one would think, disabling is specifically undoing enabling, and there's a state where it's neither enabled nor disabled and that's "they're not using jarJar". As to why there's some argument wackiness -- that's fallout of me trying to shove stuff into that system in a somewhat workable fashion