asciidoc/use/deliver.adoc

////
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     https://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
////

Deliver a resolved descriptor of the current module, and possibly perform a recursive delivery of dependencies.

This task does two main things:

== Generate a resolved Ivy file

This task generates a resolved descriptor of the current module, based upon the last resolve done. The resolved Ivy file contains updated information about the delivered module, such as revision and status.

Moreover, all included configurations' files are included in the Ivy file, and variables are replaced by their values.

Finally, in the resolved Ivy file, dynamic revisions are replaced by the static ones that have been found during the resolve step, so the Ivy file can be used later safely to obtain the same dependencies (providing that a revision uniquely identifies a module, which should be the case for proper Ivy use).

(*__since 1.3__*) The replacement of dynamic revisions by static ones can be turned off, so that dynamic revisions are kept in the Ivy file. This is an exception to the recommended standard that published module descriptors be fully resolved, so use it with caution.

== Recursive delivery

This is done only if a deliver target is given to the deliver task.

If a deliver target is set, then it is called (via an `antcall`) for each dependency which has not a sufficient status compared to the deliver status set for this task. This means that if you deliver an integration revision, no recursive delivery will be done.

If you deliver a milestone or a release revision, deliver target will be called with each integration dependency.

The deliver target is called with the following properties available:

* `dependency.name`: the name of the dependency to recursively deliver
* `dependency.published.status`: the status to which the dependency should be delivered
* `dependency.published.version`: the revision to which the dependency should be delivered
* `dependency.version`: the revision of the dependency that should be delivered (the one that was retrieved during last resolve)

Both `dependency.published.status` and `dependency.published.version` can be either asked to the user through Ant input tasks (default behaviour), or be always the same for the whole recursive delivery process if the following properties are set:

* `recursive.delivery.status`: set to the status to which all dependencies requiring to be delivered will be
* `recursive.delivery.version`: set to the version to which all dependencies requiring to be delivered will be

Usually the deliver target itself triggers an another Ant build (using the `ant` task) even if this is up to you to decide.

The delivered Ivy file will update its dependency revisions with those given here.

== deliver and publish

The `deliver` task is most of the time not called explicitly, but rather called automatically by the link:../use/publish{outfilesuffix}[publish] task. So, when shall the deliver task be called explicitly? When you actually need to separate what is performed by the deliver task (see above), from what is performed by the `publish` task, i.e. upload a module to a repository.

And this can be particularly useful if you want to process the generated Ivy file before uploading it (if you want to add automatically more information like an SCM tag used, the user who performed the release, ...).

It can also be useful if you want to trigger a recursive delivery and then ensure that you get the recursively delivered modules as dependencies. In this case your build order may look like this:

- `ivy:configure`
- `ivy:resolve`
- `ivy:deliver` with recursive delivery
- `ivy:resolve` again with the Ivy file generated by the recursive delivery
- do your build stuff (compile, jar, whatever)
- `ivy:publish`

== Attributes

[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|deliverpattern|the pattern to use for Ivy file delivery|No. Defaults to `${ivy.deliver.ivy.pattern}`
|pubrevision|the revision to use for the publication|No. Defaults to `${ivy.deliver.revision}` if set, or the revision resolved if set, or a timestamp
|pubbranch|the branch to use for the publication|No. Defaults to `${ivy.deliver.branch}` if set, or the branch resolved if set, or nothing (branch info won't be updated)
|pubdate|the publication date to use for the publication. This date should be either `now`, or a date given with the following pattern: `yyyyMMddHHmmss`|No. Defaults to `now`
|status|the status to use for the publication|No. Defaults to `${ivy.status}`
|delivertarget|the target to call for recursive delivery|No. No recursive delivery is done by default
|validate|`true` to force Ivy files validation against ivy.xsd, `false` to force no validation|No. Defaults to default Ivy value (as configured in settings)
|replacedynamicrev|`true` to replace dynamic revisions by static ones in the delivered file, `false` to avoid this replacement (*__since 1.3__*)|No. Defaults to `true`
|replaceForcedRev|`true` to replace revisions (static or dynamic) by the revision of the resolver in link:../settings/resolvers{outfilesuffix}#common[forced mode], `false` to avoid this replacement (*__since 2.2__*)|No. Defaults to `false`
|merge|if a descriptor link:../ivyfile/extends{outfilesuffix}[extends] a parent, merge the inherited information directly into the delivered descriptor.  The `extends` element itself will be commented out in the delivered descriptor. (*__since 2.2__*)|No. Defaults to `true`.
|settingsRef|A reference to Ivy settings that must be used by this task (*__since 2.0__*)|No. Defaults to `ivy.instance`.
|conf|comma-separated list of configurations to include in the delivered file. Accepts wildcards. (*__since 2.0__*)|No. Defaults to all configurations
|generateRevConstraint|`true` to automatically generate a `revConstraint` attribute in the delivered file (see the link:../ivyfile/dependency{outfilesuffix}[dependency] page for more info about this attribute), `false` to never generate this attribute (*__since 2.1__*)|No. Defaults to `true`
|=======

== Example

Deliver an Ivy file without the private configurations:

[source,xml]
----
<deliver conf="*(public)"/>
----