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>
Related
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.
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.
I want to use a third party jar file to be used in my ant project.
I guess that I should add something in build.xml file.
Actually I want to add Jsoup dependency in my build file.
I have read somethings after google search but i could not find out.
I already have tried
<classloader loader="system">
<classpath>
<fileset dir="${basedir}" includes="jsoup-1.6.2.jar"/>
</classpath>
</classloader>
Can someone tell me how can I do this ?
Here is one way to add a jar to your javac classpath.
<javac srcdir="${src}" destdir="${classes}">
<classpath>
<pathelement location="jsoup-1.6.2.jar"/>
</classpath>
</javac>
You could also define the classpath outside the scope of javac (e.g. at top-level of your build file) and then refer to it by id in your javac task.
Thanks for your reply. But later on I managed to solve the problem.
Since this is ant project. There is an ivy.xml so just adding ant dependency of jsoup in ivy.xml works fine.
I am defining a new task in Ant.
I exported it as a jar and added to my buildfile:
<taskdef classname="X" classpath="Y.jar"/>
The problem is that this fails at runtime.
It tells me it didn't find the class.
By adding the jar to the classpath, it is corrected.
My question is: Is there a way that I can refer to my jar from the Ant buildfile, without changing the classpath?
If you know the path of your jar, inside ant script you can define the classpath for your own task.
<taskdef name="myTaskName" classname="com.myorg.myclass">
<classpath>
<pathelement location="pathToMyJar.jar"/>
</classpath>
</taskdef>
Yes. I'm assuming that you looked at the doc for taskdef, which just shows the task name and implementing class. However, taskdef subclasses typedef, and if you look at the doc for the latter you'll see that there's also a classpath attribute.
HOWEVER, using this attribute means that your ant scripts are tied to a particular environment; they aren't very portable. A far better approach is to pass the classpath into Ant, using the -lib invocation option.
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>