We have a legacy project that uses ANT for building. It uses the maven ant task plugin for handling dependencies against our Nexus server.
We now want to use a common settings.xml file for this ANT project and our other maven projects to minimize the hassle.
The ant project has a dependency file containing "dependency sets"
<artifact:dependencies filesetId="foo" settingsFile="ant-settings.xml">
<dependency ....>
</artifact:dependencies>
<artifact:dependencies filesetId="fum" settingsFile="ant-settings.xml">
<dependency ....>
</artifact:dependencies>
In the settings file used by the ANT project we have a profile set to "active by default".
We can't put this profile in the common settings file as it will mess it up for the maven projects and the ANT project will not build without the profile.
Is there a way to do this and keep all projects happy?
/J
In our dependencies file I added
<artifact:remoteRepository id="foo" url="nexus path" />
To all artifact:dependencies I add
<remoteRepository refId="foo" />
at the end.
i.e:
<artifact:dependencies filesetId="foo" settingsFile="ant-settings.xml">
<dependency ....>
<remoteRepository refId="foo" />
</artifact:dependencies>
Related
I need to build my multi module application using ant build tool, I am unable find suitable documents. I have few doubts.
Actually our application consists of 7 modules out of which 1 is EAR module(Currently we are building through eclipse without using any build tool).
So my doubt is
can i write a single build.xml i.e in EAR module(EAR project) for building project or do i need to write build.xml for every modules?
and also our project has cyclic dependencies, so is it possible to build using Ant without solving those cyclic dependencies....?
Thanks in advance
you should have separate build.xmls for all of your modules. build.xml of your ear module should call all other module's build files and finally export the ear with ear task which may look like;
<property name="build.dir" value="/path/to/your/build-directory/" />
<property name="src.dir" value="/path/to/ear-module/" />
<target name="generate-module-jars">
<!-- this should build module and export module jar to ${build.dir} -->
<ant antfile="module1/build.xml" target="jar" />
<!-- this should build module and export module jar to ${build.dir} -->
<ant antfile="module2/build.xml" target="jar" />
<!-- this should build module and export module jar to ${build.dir} -->
<ant antfile="module3/build.xml" target="jar" />
</target>
<target name="export-ear" depends="generate-module-jars">
<ear destfile="${build.dir}/myapp.ear" appxml="${src.dir}/metadata/application.xml">
<fileset dir="${build.dir}" includes="*.jar,*.war"/>
</ear>
</target>
You should reorganize your modules removing cyclic dependencies. But still you can use ivy. Or you can self implement an ant task directly calling eclipse's compiler that can handle cyclic dependencies. (if you are using eclipse)
I'm trying to build an executable jar file using ant managed by ivy but am stuck. Our original build-script assembles the jar file more or less okay. The dependencies are in the manifest.mf but not under Class-Path but rather Compile-Class-Path entry.
I can simply set the Main-Class entry in the menifest file but having an impossible foe in trying to get the ivy dependencies in the Class-Path. While this seems simple enough using gradle I can't find any solution for ivy dependencies.
Is there a way of getting the resolves ivy dependencies and put them in the manifest? These dependencies are just paths to a network location where the jar files are.
I'm giving a standard way to do this. If you can provide your actual build file, I can be more specific in the answer.
You can do this in the ant target for jar creation. For ex:
<!-- create a classpath variable with all the jars needed for runtime -->
<path id="cls.path">
<!-- declare all the paths that you need. For ex: all resolved jars in "runtime" conf -->
</path>
<!-- If your path has folder prefix, you'll have to do <pathconvert> -->
<jar jarfile="${jar_name}" basedir="${classes.dir}">
<manifest>
<attribute name="Class-Path" value="${cls.path}"/>
...
<!-- You can add standard jar properties and any custom property here -->
</manifest>
</jar>
I am dealing with a project using using ANT to build the source code into a EAR. The project over couple of years has grown to a mammoth size, more than fifty modules, and not surprisingly it takes 2 hours to build the source code.
The obvious decision that I made was to migrate this to a modular build using IVY for dependency management between sub-modules of the EAR, so I build only the modules that have changed and then package a new EAR every time. I am stuck trying to find out a good way of figuring out dependencies between these sub-modules. Note that 3rd party dependencies were easy to crack. I simply move all that is in the lib folder of these sub-modules to IVY. But, the former is where I am stuck.
This is what they do:
Copy source from all modules to a directory
Compile "everything" into a global.jar
Add this global.jar to the classpath
Build every individual module thereafter
Now how do I figure out that for example Module C depends on module A and B and so A and B should go as ivy dependency in the former? One way could be to add one module at a time in eclipse and try building, and then eleminate failures because of missing classes; but there has to be a better way than this, I cannot imagine spending the next one month of life figuring that out :)
First of all you need to create ivy repository. I don't know how to do it. Try to find it on ivy site. After that you need to create build.xml and ivy.xml file.
Example build.xml which builds some product which depends on module1
<project name="ivy.test" xmlns:ivy="antlib:org.apache.ivy.ant">
<target name="resolve">
<!-- this line tells ivy to use ${ivy.settings.file} where are ivy repositories; more info http://ant.apache.org/ivy/history/latest-milestone/settings.html -->
<ivy:configure file="${ivy.settings.file}"/>
<!-- resolve ivy dependencies from ivy.xml and put them in ivy cache dir -->
<ivy:resolve file="${build.dir}/ivy.xml" transitive="false" />
<!-- finally copy resolved dependencies to ${ivy.lib.dir} -->
<ivy:retrieve conf="default" pattern="${ivy.lib.dir}/[artifact].[ext]" />
</target>
</project>
Example ivy.xml used to resolve dependencies (will try to find module1 in one of ivy repository defined in ivysettings file)
<ivy-module version="2.0">
<info organisation="your.organisation" module="modulename">
<ivyauthor name="yourname" />
</info>
<configurations>
<conf name="default" description="default conf" />
</configurations>
<dependencies>
<dependency name="module1" org="your.organisation" rev="latest.release" conf="default->default" />
</dependencies>
</ivy-module>
Example ivy.xml used by module1 project (this project depends on module2 and module3; module1 is also published in repository)
<ivy-module version="2.0">
<info organisation="your.organisation" module="module1"> <!-- module name is used in dependency -->
<ivyauthor name="yourname"/>
</info>
<configurations>
<conf name="default" description="default configuration"/>
</configurations>
<publications>
<artifact name="module" ext="dll" type="dll" conf="default"/>
</publications>
<dependencies>
<dependency name="module2" org="your.organisation" rev="latest.release" conf="default->default" />
<dependency name="module3" org="your.organisation" rev="latest.release" conf="default->default" />
</dependencies>
</ivy-module>
So, let's assume that I have an already installed SVN and installed ANT / Ivy locally.
I want to have the "shared" part of the ivy config point to some kind of share on a server. How would I need to set this up?
I know I have to dig through the ivy jar and pull out the ivysettings file and modify shared repositories.
So let's assume that I have a server on my intranet at MyServer.intranet.net and my team's folder was under /path/to/NetAdmin (thus the full path would be MyServer.intranet.net/path/to/NetAdmin ) How would I get this set up as a team repository for shared libraries? Would I just specify it and when I package the projects it writes the dependencies there?
Thanks
Here what I did:
I created a Subversion project called ivy.dir.
In this ivy.dir project, I have the latest ivy.jar.
In the ivy.dir, I have the ivysettings.xml setup for our environment. For example, we use a local Artifactory Maven repository for our own jars. The ivysettings.xml in the ivy.dir project points to that.
I created a file called ivy.tasks.xml. This is an Ant build file.
The ivy.tasks.xml looks like this:
<project name="Ivy.Tasks"
xmlns:ivy="http://ant.apache.org/ivy"
xmlns:jacoco="antlib:org.jacoco.ant">
<property environment="env"/>
<!-- Add Ivy Tasks -->
<taskdef uri="http://ant.apache.org/ivy"
resource="org/apache/ivy/ant/antlib.xml">
<classpath>
<fileset dir="${ivy.dir}">
<include name="ivy*.jar"/>
</fileset>
</classpath>
</taskdef>
<ivy:settings file="${ivy.dir}/ivysettings.xml"/>
</project>
Notice that I have my own Ivy settings, thank you. I didn't have to munge up the one in the ivy.jar (although I could have since everyone will use my ivy.jar file!). My ivysettings.xml looks like this:
<ivysettings>
<!-- I'll explain this part below -->
<property name="env.EXECUTOR_NUMBER" value="0" override="false"/>
<caches
defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}"
resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/>
<!-- Just the standard stuff you find in the `ivysettings.xml in the ivy.jar -->
<settings defaultResolver="default"/>
<include file="${ivy.dir}/ivysettings-public.xml"/> <!-- This one is different -->
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
The big change is the ivysetting-public.xml file:
<ivysettings>
<resolvers>
<ibiblio name="public"
m2compatible="true"
checkmodified="true"
root="http://repos.vegicorp.com/artifactory/libs-release" />
</resolvers>
</ivysettings>
It's pointing to my local Maven repository -- my Artifactory server.
Now, for a developer to use Ivy, all they have to do is:
In the root of their project in Subversion, add a svn:external. This svn:external will be used to bring my ivy.dir project into their Subversion project.
In the build.xml
Add an Ivy namespace definition to their build.xml in the <project> definition.
Set the property ivy.dir to `${basedir}/ivy.dir.
Use the <import> task to import ${ivy.dir}/ivy.tasks.xml into their build.xml file.
Something like this:
<project name="post-a-matic" default="package" basedir="."
xmlns:ivy="http://ant.apache.org/ivy">
<property name="ivy.dir" value="${basedir}/ivy.dir"/>
<import file="${ivy.dir}/ivy.tasks.xml"/>
<!-- A whole bundle of properties are set -->
<target name="clean">
<delete dir="${target.dir}"/>
<ivy:cleancache/> <!-- Look: They have access to Ivy! -->
</target>
<target name="-resolve">
<ivy:resolve/>
</target>
<target name="compile"
depends="-resolve">
<ivy:cachpath
pathid="main.classpath"
conf="compile,provided"/>
<!-- Boy that's easy! -->
<javac srcdir="${main.srcdir}"
destdir="${main.destdir}"
classpathref="main.classpath"/>
</target>
<!-- On and on -->
This solves a lot of problems:
You can update the ivy.settings and everyone will have the updated settings. This ended up being very important to us because we use Jenkins and I wanted Jenkins to clean the ivy cache on each build. Whoops! That cleans out the ivy cache on builds that are being executed at the same time! I solved the problem by changing the ivysettings.xml file to define a different Ivy cache for each Jenkins build executor. One the Jenkins server, you have Ivy caches called $HOME/.ivy2/cache-0, $HOME/.ivy2/cache-1, etc. Each executor can delete it's own Ivy cache without affecting the others. Users, meanwhile will just have $HOME/.ivy2/cache-0.
You also can update Ivy when a new jar comes out. You update your Ivy jar file, and everyone gets the lated.
Big one of course is that Ivy installs itself when a project is checked out.
And an extra special bonus: You could use your ivy.dir and ivy.tasks.xml file to install other tasks. For example, each of our projects must run itself through Findbugs, PMD, CPD (part of the PMD project, Checkstyle, and use JaCoCo. for test coverage.
Each one of these projects consist of a jar file, and a <taskdef> to pull the task definitions into Ant. And, how do you use these tasks too? They're not defined in the standard Ant model. Developers don't know how to use them.
I've added these jars into my ivy.dir project, and installed all of those task definitions into my ivy.tasks.xml file. I also defined easy to use <macrodef> for most of these tasks, so it's easy for the developers to use them. In fact, I've even included the old Ant-Contrib tasks just for fun.
Now, once you add ivy.dir into your project, you have all of these extra tasks, and you have nothing to install on your machine.
You don't need to change the ivy jar. Just create a filesystem resolver in an ivysettings file and publish to this. Here's an example:
good ivy tutorial for local repository?
You'll find that ivy is very flexible and can support pretty much any mechanism for hosting files.
Personally, I'd consider installing a Maven repository manager like Nexus or Artifactory and use this to host both your builds dependencies and build outputs. In the long run it's a lot easier, especially if you're doing Java development.
At our company, we use a base ant file that is included by everyone to do their builds. It contains the things we want to define globally and uniform, like build-test, test-coverage, build-release, publish on ivy, etc.
I would like to enforce that in the ivy resolve that is done for creating a release build, libraries that have test (integration) status are rejected. Basically, that for a release build, you can only use release-class libraries.
However, I cannot find a way to enforce this in the ivy resolve ant task (not in the ivy.xml file).
Does anybody have an idea on how to accomplish this?
Option 1
Strictly speaking you have two sets of resolved libraries, so this could be solved by having two ivy files. One listing dependencies on the latest integration revisions the other the latest release versions.
The build.xml file would then have two resolution targets, controlled by a release property
<target name="resolve-int" unless="release.build">
<ivy:resolve file="ivy-int.xml"/>
</target>
<target name="resolve-rel" if="release.build">
<ivy:resolve file="ivy-rel.xml"/>
</target>
<target name="resolve" depends="resolve-int,resolve-rel"/>
Option 2
Use a property to determine the desired dynamic revision:
ivy.xml
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<dependencies>
<dependency org="commons-lang" name="commons-lang" rev="${dynamic.revision}"/>
</dependencies>
</ivy-module>
build.xml
The property dynamic.revision has a default value of latest.integration
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="demo-ivy" default="resolve">
<property name="dynamic.revision" value="latest.integration"/>
<target name="resolve">
<ivy:resolve/>
</target>
..
</project>
A release build would then override this value, possibly from the command-line as follows:
ant -Ddynamic.revision=latest.release