skip to content

What is the difference between from() and setFrom() on a ConfigurableFileCollection?

level: middleimportance: must knowfreq 50%

answer

  1. from = append / accumulate
  2. setFrom = replace / reset
  3. convention defaults → setFrom
  4. user augmentation → from
  5. both stay lazy

basics

~10 s

from(...) appends new sources to whatever is already there; setFrom(...) replaces all existing sources with exactly what you pass. Use from to accumulate, setFrom to reset.

solid answer

~40 s

Both methods configure the sources of a `ConfigurableFileCollection`, but with opposite accumulation semantics. **`from(Object...)`** *adds* the given sources on top of any already registered — it's additive, so calling it repeatedly builds up the collection. **`setFrom(Object...)`** *replaces* the entire set of sources with exactly what you pass, discarding anything added before. In Kotlin DSL, assigning to the property (`collection.setFrom(x)` or via the convenience of clearing then adding) maps to replacement, while `from` is the accumulating builder. A common bug is calling `from` in a loop expecting replacement and ending up with a growing collection; `setFrom` is the right tool when a plugin convention should establish the *only* sources. Both keep evaluation lazy — they record sources, they don't resolve files.

code

kotlin · 4 lines
kotlin
val cp = project.objects.fileCollection()
cp.from("libs/a.jar")
cp.from("libs/b.jar")   // a.jar + b.jar
cp.setFrom("libs/c.jar") // now ONLY c.jar

go deeper

for a junior

Recall that from adds and setFrom replaces.

for a middle

Explain the accumulation bug and when a plugin should choose each, plus the Kotlin DSL no-assignment gotcha.

for a senior

Reason about convention-vs-augmentation: plugin establishes defaults with setFrom on apply, users augment with from.

for a principal

Define team conventions so plugin APIs don't clobber downstream configuration; document additive contracts on exposed file-collection properties.

## The two mutators A `ConfigurableFileCollection` exposes two ways to set its contents: ### `from(Object... paths)` — additive Appends the given sources to whatever the collection already holds. Each call adds more. This is the natural "builder" method: ```kotlin val cp = objects.fileCollection() cp.from("libs/a.jar") cp.from("libs/b.jar") // collection now has BOTH ``` ### `setFrom(Object... paths)` — replacing Clears the current sources and sets them to exactly the arguments given: ```kotlin cp.setFrom("libs/only.jar") // discards a.jar and b.jar; now just only.jar ``` ## Why the distinction matters Plugins frequently expose a `ConfigurableFileCollection` extension property and let users *augment* it with `from`. But a plugin establishing a **convention** (the default/only sources) should use `setFrom` so it doesn't silently pile onto user input. Conversely, library code that should respect user additions must avoid `setFrom`, which would wipe them out. ## Lazy semantics are identical Neither method resolves files. They both accept the same permissive argument types (`File`, `String`, `Provider`, `FileCollection`, `Callable`/closure) and defer resolution to query time. The only difference is accumulate-vs-replace. ## Kotlin DSL note In the Kotlin DSL, `ConfigurableFileCollection` is not assignable with `=` to a raw value the way a `Property<T>` is; you call `setFrom(...)` explicitly (or `from(...)` to add). This trips up people who expect `cp = files(...)` to work. ## Common mistake ```kotlin listOf("a", "b", "c").forEach { cp.from(it) } // grows to 3 — usually intended cp.setFrom("a") // resets to exactly 1 ```

  • In the Kotlin DSL, why can't you write cp = files(...) for a ConfigurableFileCollection?
    ConfigurableFileCollection is not a Property<T> and has no assignment operator overload; you must call setFrom(...) to replace or from(...) to add. Only Property/Provider-backed types support = in the Kotlin DSL.
  • A plugin wants to set default sources but still let users add more. Which method should the plugin use, and where?
    Use setFrom for the initial default during plugin apply (establishing the convention), then expose the property so users call from to augment. Don't have the plugin call setFrom after users have configured it.

saying these in an interview costs you the question

  • Saying from() replaces the collection — it appends.
  • Claiming setFrom is just an alias for from.
  • Using = assignment on a ConfigurableFileCollection in Kotlin DSL and expecting it to compile.

context

resolving links…