I have a super wonderful task that populates a path id...
<ivy:cachepath organisation="XXXX" module="ZZZZ" revision="0.2.4-SNAPSHOT" inline="true" pathid="mypath"/>
Without writing complex Java code is there a way to convert "mypath" into something the ant task could accept? I'd really like to specifically delete these cache files (I"m working around a bug in Ivy that it doesn't actually re-fetch snaphots).
This worked for me:
<path id="test">
<pathelement path="${basedir}/foo"/>
<pathelement path="${basedir}/bar"/>
</path>
<delete>
<path refid="test"/>
</delete>
I didn't use <ivy:cachepath/>, but I did create a Path ID and was able to delete the individual elements using the Path as an refid.
Don't understand what you're trying to do. Most ANT tasks accept classpath references, which is what the ivy cachpath task creates. Secondly deleting files from the ivy cache seems suspect... Sort of defeats the purpose of using ivy :-)
But you asked, so I'd recommend using an ivy retrieve instead as follows:
<ivy:retrieve pattern="${build.dir}/lib/[artifact](-[classifier]).[ext]">
<dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="default"/>
<dependency org="org.slf4j" name="slf4j-simple" rev="1.7.5" conf="default"/>
</ivy:retrieve>
<path id="mypath">
<fileset dir="${build.dir}/lib" includes="*.jar"/>
</path>
Note:
Nested dependency declarations requires ivy > 2.3.0
Update 1
I suspect your ivy "bug" fetching snapshots is actually an issue with your ivy settings file. Only ibilio resolvers understand Maven's internal mechanism for tracking snapshots. For more information read about the "m2compatible" and "useMavenMeta" options.
Update 2
Are you publishing snapshots from ivy into a Maven repository like Nexus?
Yeah... That's a known issue. Possible work-arounds to consider are here:
Publishing Ivy SNAPSHOTS with Maven metadata
What's wrong with this Ivy changingPattern / SNAPSHOT configuration?
My advise would be to avoid snapshot releases unless you need to work with Maven projects. ivy has a wonderful buildnumber task that makes generating unique builds a snap. Opinions differ.
Related
After migrating from pure ant to ant+ivy my project build times increased from 7s to 26s while incremental rebuilds are now 7s instead of just under 1s (nearly instant).
Most of this time seems to be spent in ivy:resolve which I need to generate classpath using ivy:cachepath.
Is there some way to speed this up, especially rebuilds ?
Another option is to switch off network based resolution and force ivy to use cached data.
See the following answer for more details:
Resolving Apache Ivy dependencies when offline/disconnected?
Are you using <ivy:cleancache>? This is why your rebuilds are so short, but your initial builds are so long.
Ivy is going to be slower than using Ant without Ivy. Ivy has to download each and every jar you specify, plus all dependencies into the Ivy cache (which by default is $HOME/.ivy2/cache on Unix/Mac/Linux and %USERPROFILE%\.ivy2\cache on Windows) before it can begin. You might specify 4 or 5 jars, but these could depend upon others which might depend upon even more.
There really isn't a way to speed up the Ivy downloading of jars1, but once jars are downloaded, there really isn't a reason to constantly clean the Ivy cache each and every time you do a new project, or when you do a clean.
What you can do is setup your clean, so you can avoid cleaning the Ivy cache unless you specify it:
<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>
<property name="ivy.cleancache" value="false"/>
<target name="clean">
<if>
<istrue value="${ivy.cleancache}"/>
<then>
<ivy:cleancache/>
</then>
<if>
<delete dir="${target.dir}"/>
</target>
This way, running ant clean won't scrub your Ivy cache every time, and you can reuse it over and over again. If you want to clean the Ivy cache you need to do this:
ant -Divy.cleancache=true clean
Yes, this is using antcontrib. I use my special Ivy directory configuration to configure Ivy for everyone and while I'm at it, to include definitions for ant-contrib, plus Findbugs, PMD, and other useful tools.
However, it might be possible in Ant 1.9 not to have to do this:
<property name="ivy.cleancache" value="false"/>
<target name="clean">
<ivy:cleancache if:true="ivy.cleancache/>
<delete dir="${target.dir}"/>
</target>
I haven't tried this, but if it works, you don't have to use antcontrib. Of course, you could do this too:
<target name="ivy.cleancache"
if="ivy.cleancache">
<ivy:cleancache/>
</target>
<target name="clean"
depends="ivy.cleancache">
<delete dir="${target.dir}"
</target>
Then you could specify:
$ ant -Divy.cleancache clean
to clean your Ivy cache and simply put ant clean to clean your build without cleaning the Ivy cache.
1. You might be able to speed up the downloading of jars if you use your own Maven repository like Nexus or Artifactory. These will have their own cache which will store the downloaded third party jars locally. This is a bit faster than going outside your network to find these third party jars, but they all still have to be downloaded. Maybe instead of taking 26 seconds, it might only take 20 seconds.
Try this -Divy.checkmodified=false / -Divy.skip=true
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.
The reason we are using IVY is that we already have ANT scripts. Meaning, there is no maven compatible folders by default.
We had to create such convention.
Now, I already implemented the IVYing. After resolve, I do the
<ivy:cachepath pathid="ivy.test.classpath" conf="test" settingsref="ivy.ref" />
The problem with this, it doesn't include the
src/test/java , src/test/resources
What is the best way of including those.
What I'm currently doing is creating another classpath (postfixed with .extended) that includes the original classpath along with the new folders.
Is there an 'IVYier' way to do it? maybe add something in the dependency file ivy.xml or a way to tell it to act maven.
Thanks in advance
Why do you need to add the source dirs to the classpath?
I typically only need to add the compiled classes directory into a classpath and that is typically easier to do directly in the few tasks like Junit that needs to be configured in this manner.
For example:
<junit ....>
<classpath>
<path refid="runtime.path"/>
<pathelement path="${classes.dir}"/>
</classpath>
..
</junit>
I have a build.xml(ant based) which requires some jar from nexus to get copied in existing lib folder. i.e when it builds it should copy the jar from nexus with some version defined & then copy in lib & do compilation.
like happen in maven we define the artifact & its version . If changed will automatically download it from maven repo.
how can i do this in ant based builds?
experts pls advice.
I have taken the example listed in this thread one step further and created a macrodef to clean things up a bit for re-use. See below for downloading two artifacts from nexus (one snapshot, one release).
<project>
<target name="get-all">
<mkdir dir="lib" />
<nexus-get
groupId="foo.bar"
artifactId="some-artifact"
version="1.0.28"
repo="releases"
extension="jar"
dest="lib"
/>
<nexus-get
groupId="foo.bar"
artifactId="another-artifact"
version="1.0.0-SNAPSHOT"
repo="snapshots"
extension="jar"
dest="lib"
/>
</target>
<macrodef name="nexus-get">
<attribute name="groupId"/>
<attribute name="artifactId"/>
<attribute name="version"/>
<attribute name="repo"/>
<attribute name="extension"/>
<attribute name="dest"/>
<sequential>
<get src="http://my-nexus:9999/nexus/service/local/artifact/maven/redirect?r=#{repo}&g=#{groupId}&a=#{artifactId}&v=#{version}&e=#{extension}" dest="#{dest}/#{artifactId}.#{extension}" usetimestamp="true" />
</sequential>
</macrodef>
You would probably be interested in Ivy. It is a sub-project of Ant for dependency management. It is perfect for your situation because it can read Maven repositories and provides Ant tasks for downloading the published artifacts, constructing class paths from them, etc. It supports your use case of getting the most recent version of a dependency if you configure it to ask for the "latest.release" revision of the module.
Although there are surely specific ways to combine ant and maven the simplest thing (if you know the nexus URL and your artifact parameters to construct the download URL) would be just to use the ant Get task.
<project name="MyProject" default="resolveDependencies" basedir=".">
<target name="resolveDependencies">
<mkdir dir="lib" />
<get src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar" dest="lib/log4j-1.2.9.jar" usetimestamp="true" />
</target>
</project>
Perhaps use the Maven Ant Tasks.
As shown on http://maven.apache.org/ant-tasks/examples/dependencies.html
Can list dependencies in ant, and also do things like copy them
I think the section Using FileSets and the Version Mapper covers your need
You can use is filesetId, which will give you a fileset reference that can be used to copy files into a particular location. For example, to populate WEB-INF/lib with your dependencies you could use the following:
<artifact:dependencies filesetId="dependency.fileset" useScope="runtime">
<dependency groupId="junit" artifactId="junit" version="3.8.2" scope="test"/>
</artifact:dependencies>
<copy todir="${webapp.output}/WEB-INF/lib">
<fileset refid="dependency.fileset" />
<!-- This mapper strips off all leading directory information -->
<mapper type="flatten" />
</copy>
Is there a well-established way to share Ant targets between projects? I have a solution currently, but it's a bit inelegant. Here's what I'm doing so far.
I've got a file called ivy-tasks.xml hosted on a server on our network. This file contains, among other targets, boilerplate tasks for managing project dependencies with Ivy. For example:
<project name="ant-ivy-tasks" default="init-ivy"
xmlns:ivy="antlib:org.apache.ivy.ant">
...
<target name="ivy-download" unless="skip.ivy.download">
<mkdir dir="${ivy.jar.dir}"/>
<echo message="Installing ivy..."/>
<get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
dest="${ivy.jar.file}" usetimestamp="true"/>
</target>
<target name="ivy-init" depends="ivy-download"
description="-> Defines ivy tasks and loads global settings">
<path id="ivy.lib.path">
<fileset dir="${ivy.jar.dir}" includes="*.jar"/>
</path>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
uri="antlib:org.apache.ivy.ant"
classpathref="ivy.lib.path"/>
<ivy:settings url="http://myserver/ivy/settings/ivysettings-user.xml"/>
</target>
...
</project>
The reason this file is hosted is because I don't want to:
Check the file into every project that needs it - this will result in duplication, making maintaining the targets harder.
Have my build.xml depend on checking out a project from source control - this will make the build have more XML at the top-level just to access the file.
What I do with this file in my projects' build.xmls is along the lines of:
<property name="download.dir" location="download"/>
<mkdir dir="${download.dir}"/>
<echo message="Downloading import files to ${download.dir}"/>
<get src="http://myserver/ivy/ivy-tasks.xml" dest="${download.dir}/ivy-tasks.xml" usetimestamp="true"/>
<import file="${download.dir}/ivy-tasks.xml"/>
The "dirty" part about this is that I have to do the above steps outside of a target, because the import task must be at the top-level. Plus, I still have to include this XML in all of the build.xml files that need it (i.e. there's still some amount of duplication).
On top of that, there might be additional situations where I might have common (non-Ivy) tasks that I'd like imported. If I were to provide these tasks using Ivy's dependency management I'd still have problems, since by the time I'd have resolved the dependencies I would have to be inside of a target in my build.xml, and unable to import (due to the constraint mentioned above).
Is there a better solution for what I'm trying to accomplish?
If you are using ANT 1.8+, then you could just import the build.xml directly from the hosted location.
http://ant.apache.org/manual/Tasks/import.html
Since Ant 1.8.0 the task can also
import resources from URLs or
classpath resources (which are URLs,
really). If you need to know whether
the current build file's source has
been a file or an URL you can consult
the property ant.file.type.projectname
(using the same example as above
ant.file.type.builddocs) which either
have the value "file" or "url".
<!-- importing.xml -->
<project name="importing" basedir="." default="...">
<import file="http://myserver/ivy/ivy-tasks.xml"/>
</project>
If you use Antlibs you can package them all inside a JAR file. Then simply copy this file into the ${ANT_HOME}/lib directory to use them.
After some additional searching, a possible solution would be to use SVN externals to check out specific required files that may be needed by the build.xml.
However, this would only work for users who are using Subversion as source control. It would still be nice to have a SCM-agnostic solution for users who aren't using Subversion, or another SCM that supports similar functionality.
What we've done is to create a project called 'bootstrap' which contains the various xml-files needed for the other projects at our office.
So to set up your development environment you run build.xml in bootstrap which copies the xml-files (like your ivy-stuff, and other targets) to a known location, and then your build files include these like this:
<import file="${ant.bootstrap.dir}/ant-commons.xml" />
<import file="${ant.bootstrap.dir}/ant-commons-ear.xml" />
Our bootstrap build.xml contains this:
<target name="install">
<fail unless="ant.bootstrap.dir" message="ant.bootstrap.dir ${missing.property.message}"/>
<copy todir = "${ant.bootstrap.dir}">
<fileset dir = "src/xml"/>
</copy>
</target>