Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

This proposal is a work in progress

What?

The dependency DSL refers to the code you use in your build script to declare the artifacts which your project needs to build, and also to declare the artifacts which your project produces. This includes resolving and publishing artifacts and meta-data to repositories, and also how artifacts are shared between the projects of a build, and across multiple builds.

Why?

Here are some problems with the current DSL:

  • Does not meet the use cases listed below or doesn't make it as convenient as it should be.
  • The repository API uses ivy classes, and requires the use of the ivy API
    • The ivy API isn't particularly DSL friendly, or particularly deep.
    • Including ivy classes in the API means ivy and all its dependencies must be visible in every Gradle ClassLoader
  • Configuration is a poor name, which doesn't really convey any meaning
  • Incoming artifacts (dependencies) and outgoing artifacts (publications and meta-info) are bound together into a single Configuration interface.
    • Configurations which are used only by the project itself (eg compile, and most custom configurations) end up included in generated descriptors
  • Configuration inheritence is awkward, and difficult to map to other models (maven, osgi, ide models)
  • Cannot query the publications of a project, eg just the artifacts, or the artifacts + thier dependencies, or just the dependencies
  • Too much ceremony to resolve a single dependency (eg the dependencies an Ant task to use for a taskdef)
  • The compilation classpath contains the transitive closure of runtime classpath of all dependencies
  • Need to customise the POM in multiple places (install task and each deployer).
  • more to come

Use cases

  • Retrieving dependencies from a dependency specific set of repositories.
  • Publish several different variations of the project, for example groovy.jar vs groovy-all.jar, testng-jdk15.jar vs testng-jdk14.jar
  • Use platform-dependent artifacts for a dependencies, or produce platform-dependent artifacts.
  • Use an ivy id (organisation,name,revision) or maven id (group,artifactId,version) which is different to that of the project.
    • Must be reflected in the ivy.xml/pom.xml of other projects which have a project dependency on the project
  • Publish both the ivy.xml and pom.xml for a project to a repository
  • Query the artifacts for a given dependency in a variety of ways
    • All the transitive project artifacts
    • All the transitive external artifacts
  • Generate descriptor locally without publishing anything: pom.xml, ivy.xml, ide classpath file
  • Import dependencies from existing descriptor: ivy.xml, pom.xml, ide classpath file
  • Specify an api classpath and runtime classpath for a project, which is used by projects that depend on the project at compile time and run time, respectively
  • A project depends on artifacts which must be built after they are downloaded
    • eg source dependencies, an artifact which must be installed or unpacked in some way
  • Gradle uses the classes dir for a project dependency for compilation and unit test execution, and the jar for distribution (eg war) assembly.
  • Handle multiple different dependencies which implement the same API:
    • Replace usages of one implementation with another. For example, replace commons-logging with a compatible jcl-over-slf4j
    • Handle conflicts between different implementations. For example, treat junit and junit-dep or groovy and groovy-all as conflicting dependencies.
  • Gradle core does not depend on ivy or maven classes or concepts.
  • More to come

Model

Artifacts

  • An artifact is a binary resource.
  • An artifact has meta-data associated to it.

Dependencies

  • A project has dependencies. These are the incoming artifacts of the project, which the project needs to do its work.
  • A dependency resolves to a set of artifacts and meta-data.

Composite dependencies

  • A composite dependency is a dependency
  • A composite dependency contains other dependencies
  • A composite dependency may have its own meta-data

Artifact dependencies

  • An artifact dependency is a dependency which resolves to a single artifact.

Publications

  • A project has publications. These are the outgoing artifacts of the project, which the project produces and which are used outside the project.
  • A publication contains a set of artifacts
  • A publication has zero or more dependencies, which describe the dependencies of the publication's artifacts.
  • A publication has additonal meta-data.
  • A publication's meta-data may be available as zero or more artifacts. These are called descriptors.
    • eg pom.xml, ivy.xml, .classpath

Composite publications

  • A composite publication is a publication.
  • A composite publication contains other publications
  • A composite publication may have its own meta-data

Artifact publications

  • An artifact publication is a publication which contains a single artifact.

Project publication

  • A project publication is a local inter-project publication.
  • A project publication is a composite publication.

Maven module

  • A maven module is a composite publication
  • A maven module has zero or one main artifact publications
  • A maven module has zero or more classifier artifact publications
  • A maven module has (compile,runtime,provided,system) scopes.
  • A maven scope is a publication.
  • A maven scope contains the main artifact and dependencies.

Ivy module

  • An ivy module is a composite publication
  • An ivy module has zero or more configurations.
  • An ivy configuration is a composite publication.
  • An ivy configuration has zero or more artifacts and dependencies.

Eclipse classpath

  • An eclipse classpath is a meta-data only publication

IDEA classpath

  • An IDEA classpath is a meta-data only publication

TBD: An artifact is-a publication?

Repositories

  • A repository is a store for publications and associated meta-data.
  • A repository has a schema for the types of publications which it contains.
  • A repository may allow publications to be uploaded, that is added to the repository
  • A repository allows publication artifacts to be downloaded.
  • A repository allows publication meta-data to be queried.

TBD: uploaded should be published or deployed?

Maven repositories

  • A maven repository contains maven publications

Ivy repositories

  • An ivy repository contains ivy publications

Other repositories

  • A general purpose URL based repository.
  • A build has an implicit repository which contains the project publications for all of the projects of the build.
  • A build has an implicit repository which represents the local file system.

DSL

  • TBD
Labels
  • None