Add example for non-mc dep.

[Fealtous]

Will need updating when officially exposed.

[LexManos]

Ya this is something that needs to be thought of.
Basically its just a work around for versions where each layer has to be explicitly defined.
The question becomes how do we want to expose this to end users?
In the past a single magic 'minecraftLibrary' configurations has sufficed. But that restricts every run to have the same dependencies. Part of FG7's design is that you could have multiple runs, with different 'minecraft' dependencies, in the same project.
So should we expose this 'extraLibraries' on the run config itself?
Something like:

configurations {
  loggingToFile
  loggingToScreen
}

dependencies {
  logginToFile 'logprovider:file:1.0'
  logginToScreen 'logprovider:screen:1.0'
}

minecraft {
  runs {
    register('clientToFile') {
      extendsFrom('client')
      extraLibraries configurations.loggingToFile
    }
    register('clientToScreen') {
      extendsFrom('client')
      extraLibraries configurations.loggingToScreen
    }
  }
}

Or more likely to be the case:

configurations {
  minecraftLibrary
}
dependencies {
  minecraftLibrary 'some:discord:integration'
}
minecraft {
  runs {
    configureEach {
      extraLibraries configurations.minecraftLibrary
    }
  }
}

The other option is to attach it to the minecraft dependency itself like:

configurations {
  minecraftLibrary
}
dependencies {
  minecraftLibrary 'some:discord:integration'
}
dependencies {
  implementation minecraft.dependency(forge) {
    extraLibraries configurations.minecraftLibrary
  }
}

Less flexible, but I think easier to implement. As we are jsut trying to put things on the token replacer which is fed from the run task which is fed from the dependency. But that could easily have the RunConfig passed in.

[Fealtous]

I am more of a fan of having it declared in the run config(s) so that users have options, but I can't think of any projects off the top of my head that both use non-mc libs and also need different libs for different run configs. Pinning the more flexible solution for now & going with the easier to implement may make more sense at the moment until someone has a live use case for more configurability.

[Jonathing]

I am in favor of having it implemented per runs (see this Discord message). Aside from that, just another thing that has to go in our hypothetical, definitely real documentation (not just Javadocs) that we need to work on.