On 02/11/2011, at 4:23 AM, Luke Daley wrote: > > On 28/10/2011, at 9:13 PM, Adam Murdoch wrote: > >> We need some better names for the following things, as we head in towards >> Gradle 1.0: >> >> * The thing that represents a logical set of incoming dependencies. In the >> API, this is at various times called a Configuration or a >> ResolvableDependencies (also a ResolvedConfiguration). > > What's the relationship between this thing and DependencySet?
They're slightly different. DependencySet is simply a set of Dependency instances, with no other context. ResolvableDependencies is a DependencySet that is resolvable - as in we can convert it to a set of files and to a fully realised dependency graph. It has additional context to allow this to happen - a set of resolvers, conflict strategy, meta-data mutations, transitive flag, caching policy, etc, etc. > >> * The thing that a dependency refers to. Currently, these are called >> 'configurations', and each configuration lives in a 'module'. These are not >> the same as the 'configurations' above, but they are related (ie the >> incoming dependencies almost always become the outgoing dependencies). In >> the API, this is called a Configuration, or a ResolvedDependency. > > I don't quite follow here. Is this about mapping a logical name to a set of > physical files? At it's most abstract, a dependency refers to a set of artifacts + dependencies. We need a name for that (artifacts + dependencies) grouping. Right now, there are several such groupings you can refer to: * external dependency + ivy repo -> refers to a configuration in a module revision. * external dependency + maven repo -> refers to a scope in a module. * external dependency + flat repo -> refers to a set of files * project dependency -> refers to an outgoing configuration in a project * self-resolving dependency -> refers to a (buildable) FileCollection. Let's call them a 'foo' for now. I'd like to use this name in a few places: * Logically, when we describe how the dependency management model: A dependency refers to a foo. * In the outgoing publications of the project: A project Publication is a set of named Foo instances. * In the resolved metadata: A ResolvedDependency refers to a ResolvedFoo. > >> * The thing that the coordinates (group, module, version) refers to. >> Currently, this is called a module. > > Tricky. Maybe “SpecifiedDependency”? The key point that all the information > has been given to fix on a specific instance of a dependency. It shouldn't have 'dependency' in the name. I'm not after a name for this type of dependency. I'm after a name for what the dependency refers to. These are separate things. Let's call it a 'module' for now. Here are some facts about a module: * A module is published by a project. * A module lives in a repository. * A module has some meta-data and some artifacts. * A module has a collection of foo (from above). * A dependency can refer to a foo in a module. It's not a dependency. It exists completely independently of whether it is ever referred to by a dependency. > >> * The thing that the coordinates (group, module) refers to. This is also >> called a module. > > Tricky again. Maybe “NamedDependency”. Again, 'dependency' doesn't work here. These things are not dependencies. This is effectively the actual project that produces the module, independent of version. Let's call them 'producers' for now. Here are some facts about a producer: * A producer publishes modules, each with a separate version. * Conflict management by default uses producer to detect a conflict. ie we assume that 2 modules from the same producer cannot be used together. Which is pretty flawed really, but that's a separate discussion. * You can also exclude modules based on their producer. > > > I'll keep thinking on it. Coming up with good names in this area would be > *very* helpful for our users and also other developers. Absolutely. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
