The following answer outlines the comprehensive solution using an ivy file.
It answers a different question ("provided" dependencies) but one you will eventually face because not all the jars you use in your build will need to shipped with your application (because they already exist on tomcat).
Attempting to apply this answer to your question is not straightforward because you're resolving your dependencies in inline mode (No ivy file). Firstly I'd recommend combining your dependencies into a single path, rather than creating paths around each dependency:
<ivy:cachepath pathid="compile.classpath">
<dependency org="org.glassfish" name="javax.json" rev="1.0.4" />
<dependency org="org.glassfish.jersey.containers" name="jersey-container-servlet" rev="2.23.2" />
</ivy:cachepath>
Secondly (and to answer your question), it's the alternate ivy retrieve task that's used to place ivy files on the file system. It too can support an inline resolution as follows:
<ivy:retrieve pattern="${build.dir}/lib/[artifact].[ext]">
<dependency org="org.glassfish" name="javax.json" rev="1.0.4" />
<dependency org="org.glassfish.jersey.containers" name="jersey-container-servlet" rev="2.23.2" />
</ivy:retrieve>
<war destfile="${war.file}" webxml="${resources.dir}/web.xml">
<fileset dir="${resources.dir}" excludes="web.xml"/>
<lib dir="${build.dir}/lib"/>
</war>
So in conclusion, while this suggested answer will work, I would recommend investigating how configurations work in concert with an external ivy file to manage your dependencies. Configurations may appear challenging, but they're also very powerful.
Your other question is related. Using ivy's inline mode is convenient but not the most efficient way to use ivy. A single call to the resolve task can be used to determine all a project's dependencies and using configurations to partition these up into various classpath or filesets, etc.