I'm glad the subject of "configurations" has come up again.
I always found it a bit confusing in Gradle, so I decided
to write down my own "fine grain" ontology, in the hopes
of clarifying things for myself.
Note: I didn't try to come coin pretty names/terms.
Instead, I focused on delineating the issues.
Here's what I came up with:
[1] Build option settings
Properties, environment variables, compile switches
and whatnot that influence *what* gets built and *how*.
Build option settings clearly effect build dependencies.
For example:
o What compiler flags are used
o Will we bother to compile the security plugin thingy?
If not, we won't need library xyz or compiler pdq.
By "build option settings", I mean to include everything
that would be effected by "./Configure [options]"
if I were compiling a C++ program.
[2] Build dependencies
The libraries, command line tools, licenses, & so forth
required to build a project given the build settings
chosen. As mentioned earlier, build option settings
effect build dependencies.
[3] Build path(s)
The library & helper-app executable path(s) that
allow build dependencies to be resolved concretely
on the local system.
In both java and C++, the order in which you specify
things within a build path does matter.
For the sake of repeatability, security, and general cleanliness,
it would be nice to have separate paths for:
o java libraries (.jar files)
o platform specific libraries (.so/.dll files)
o external helper applications you need to exec
You may have one or more foobar.jar files on your system
(thereby satisfying an abstract build dependency),
but if you can't find it (or don't know which to choose),
then you're hozed.
[4] Artifact repository configuration
o How to fetch missing build dependencies
[5] Artifact installation configuration
o The mechanism used to install dependencies fetched
via an artifact repository onto the right path(s),
register them with the system, etc.
[6] Runtime path(s)
Conceptually similar to the build path, but related to
runtime (not the build). Runtime path(s) should typically
be kept as clean as possible for the sake of security,
sanity, repeatability, etc.
[7] Runtime Configuration
o OS, arch
o Jars/libs actually available
(the app may load stuff dynamically & self-configure)
o environment variables
o command line flags/switches
[8] Runtime dependencies
The set of dependencies implied by a runtime configuration,
and resolved by the runtime path(s).
If we can agree on the ideas, I think the right terms
will probably leap out at us. How does this ontology
compare to yours? Are we close?
Cheers,
-Jon
* Adam Murdoch (a...@rubygrapefruit.net) [090826 17:17]:
>
>
> Steve Appling wrote:
>> I would love to change this name. I did not come from an Ivy
>> background and have always felt this was awkward.
>>
>> I have also always felt that using configurations to store paths and
>> to specify a distribution archive were two very different uses that
>> didn't belong together. I would like to see the archive part pulled
>> out into another concept.
>>
>
> I agree. I think we have 2 separate concepts here: a project has
> dependencies, and a project has publications.
>
> Dependencies are artifacts produced outside the project, which are used
> by the project in some way, whether that is in the build script, or at
> compile time, or execution time, or whatever.
>
> Publications are artifacts produced by the project, and which are made
> available as dependencies for other projects.
>
> An artifact may be an archive, or an xsl file, or an image file, or a
> license file, or a report, or some javadoc, or whatever. It's just a
> file shared between projects.
>
>> To me, the core of configurations are named dependencies. I like:
>>
>> dependencyNames {
>> compile
>> openAPI
>> }
>>
>> dependencies {
>> compile 'commons-io:commons-io:1.4'
>> }
>>
>> I think "paths" are a little too generic. And paths.compile.asPath
>> seems a little strange :)
>>
>
> I think we should merge what is currently configurations {} into what is
> dependencies { }, as John has suggested.
>
> I prefer the implicit creation. I really don't buy the typo argument
> against it. I can't say I've ever had it happen in practise. Even if it
> does, the problem lasts about as long as it takes for Gradle to get to
> the compile task.
>
> So, I think we should have something like:
>
> dependencies {
> compile { transitive = false } // what we have in configurations { }
> compile {
> transitive = false
> dependency 'some-dep' // allow dependencies to be added directly
> to a Configuration
> dependency module('some-module') { ... }
> }
> compile 'some-dep' // this is simply a shortcut for compile {
> dependency('some-dep') }
> }
>
> I would model the elements of the dependencies container as composite
> dependencies, that is, each element is a Dependency to which other
> Dependency instances can be added. We might call it DependencySet or
> NamedDependency or CompositeDependency or DependencyConfiguration or
> something. We could get rid of configuration inheritence by allowing
> composite dependencies to be added to each other.
>
> As for dependencies {}, I think we should also merge configurations { }
> into artifacts { }, and rename it to publications { }
>
> publications {
> default {
> artifact myJar
> }
> default myJar // this is a shortcut for default { artifact(myJar) }
> }
>
> Similar to Dependency, we would have a Publication type, and number of
> implementations. One would be a single file. Another would be a
> composite Publication to which other Publications can be added.
>
> When a composite publication is published, the runtime dependencies to
> be included in the dependency descriptor are specified by the
> publications it contains. In the example above, when the 'default'
> publication is published, we know from how myJar is built, that it needs
> all the dependencies declared in the (incoming) 'runtime' dependency, so
> we just copy the dependencies across to the publication.
>
>>
>> Hans Dockter wrote:
>>> I would love to have a better name for configurations. Initially I
>>> just took this name from Ivy as I couldn't think of anything better.
>>> Even with Ivy I guess it is not a perfect name. But in the context of
>>> a build system it is really confusing.
>>>
>>> Mostly configurations are classpaths, but not always (e.g. they may
>>> contain distribution archives). Why not calling configurations paths?
>>>
>>> paths {
>>> compile "commons-io:commons-io:1.4"
>>> }
>>>
>>> paths.compile.files ...
>>>
>>> Thoughts? Better names?
>>>
>>> I know that this would be a pretty disruptive change. It would have
>>> been much better to have done this earlier. But that's why we are
>>> still pre 1.0.
>>>
>>> - Hans
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project Manager
>>> http://www.gradle.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
