ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: ivy and jars in war or ear
Date Sat, 21 Apr 2007 20:13:34 GMT
Thanks a lot, I didn't knew the task manifestclasspath.  This task
will simplify the script that I have now, based on properties.  By the
way, I have seen it is now in ant 1.7.

But still, there is one piece missing. When we have ears and wars, I
need a flexible technique to define which jars are in the wars, and
which jars are in the ear.

I think that if I move to ant 1.7, I will probably be able to use file
selectors to do that.


2007/4/20, Davide Baroncelli <>:
> > I have a web application with multiple jars.  Some jars are included directly in
the wars, but some are placed in the ear itself.
> > I would like to find an elegant solution using ivy and ant to : - package the wars
with the correct libs - generate the classpath to be placed in the MANIFEST.MF of the wars-
package the ear with the correct libs
> Hi Gilles, what we do have here is a custom build system based on ivy + ant which does
some of the things you want.
> Our ivy files define different configurations for the dependencies only needed when building,
and the ones needed at runtime. For a normal webapp we normally have three configurations:
>  - build
>  - prod
>  - stage,
> as in
>     <configurations>
>         <conf name="prod"/>
>         <conf name="stage" extends="prod"/>
>         <conf name="build" visibility="private"/>
>     </configurations>
> and we then define dependencies like this:
> <dependency org="jaspersoft" name="jasperreports" rev="latest.integration" conf="prod,build->default"/>
> or this:
> <dependency name="servlet-api" rev="latest.integration" conf="build->default"/>
<!-- per la compilazione delle classi che dipendono dai servlet -->
> when we build, we build against one of the "runtime" configurations (either prod or stage
in this case), but also resolve the "build time" configuration. For this our compilation target
depends on a "resolve" target done like this (note the "ivy-resolve" line):
>     <target name="resolve" unless="disable.library.resolution" depends="version.define"
description="retrieves dependencies with ivy">
>         <property name="ivy.revision" value="${version.number.full}"/>
>         <ivy-resolve conf="${},build"/>
>         <ivy-retrieve validate="false" pattern="${dir.lib}/[conf]/[module]/[artifact].[ext]"/>
>     </target>
> with "" being "prod" or "stage".
> So if we are building a "prod" configuration we have the "build time" libraries in the
${dir.lib}/build/[module] dir and the "runtime" ones in the ${dir.lib}/prod/[module]. For
compilation we then use a classpath like this:
>     <path id="build.classpath">
>         <fileset dir="${dir.lib}/build">
>             <include name="**/*.jar"/>
>         </fileset>
>     </path>
> and this resolves the part regarding compilation.
> Now, for what concerns webapps, ears or standalone applications, we do something like
> 1) for wars we have a preparation target doing this (among other things):
>         <copy todir="${}/WEB-INF/lib">
>             <fileset refid="${}"/>
>             <mapper type="flatten"/>
>         </copy>
> and that fileset is defined like this:
>     <fileset id="fileset.war.runtime.libs" dir="${dir.lib}/${}">
>         <include name="**/*.jar"/>
>     </fileset>
> (with "" being "prod", in this case).
> 2) for standalone applications we have a "jar preparation" target doing this:
>         <manifestclasspath property="jar.package.manifestclasspath">
>             <classpath refid="runtime.classpath"/>
>         </manifestclasspath>
>         <touch file="${jar.package.manifest}" mkdirs="true"/>
>         <jar manifest="${jar.package.manifest}"
>              destfile="${}/${}"
>              basedir="${}">
>             <manifest>
>                 <attribute name="Class-Path" value="${jar.package.manifestclasspath}"/>
>                 <attribute name="Specification-Title" value="${}"/>
>                 <attribute name="Specification-Version" value="${version.number.full}"/>
>                 <attribute name="Specification-Vendor" value="${name.enterprise}"/>
>                 <attribute name="Implementation-Title" value="${}"/>
>                 <attribute name="Implementation-Version" value="${version.number.full}
>                 <attribute name="Implementation-Vendor" value="${name.enterprise}"/>
>             </manifest>
>         </jar>
> "manifestclasspath" is a target taken from hivemind (I've found it on the web) and building
a "classpath string" suitable for insertion in a MANIFEST.MF starting from the libraries in
the "runtime.classpath"... which of course includes the libraries we have resolved through
ivy in the "prod" configuration:
>     <path id="runtime.classpath">
>         <fileset refid="fileset.libs.runtime"/>
>     </path>
>     <fileset id="fileset.libs.runtime" dir="${dir.lib}/${}">
>         <include name="**/*.jar"/>
>     </fileset>
> we then build a distribution zip where the libraries are packaged along with our application's
jar, which has the manifest above in its META-INF directory.
> 3) for now we have a single ear, and it only includes MDBs, so no web applications inside.
Should we have to do it we would probably:
>  - manage the web applications as separate ivy modules, and build them as above
>  - resolve the wars through ivy and include them in the ear,
>  - manage the ear libraries as we are doing now:
> - build the ejb-jar as above (i.e. via the manifestclasspath),
> - include the runtime libraries:
>     <target name="ear.prepare.dir.include.libraries" if="no.web.module">
>         <antcall target="jar.package"/>
>         <echo level="info" message="copying libraries into ear preparation directory"/>
>         <copy todir="${}">
>             <fileset file="${}/${}"/>
>         </copy>
>         <copy todir="${}">
>             <fileset refid="fileset.libs.runtime"/>
>             <mapper type="flatten"/>
>         </copy>
>     </target>
> I hope this is helpful for you!


View raw message