In my ivy.xml file I have dependency statements like:
<dependency conf="*->*" org="gnu" name="gcc" rev="4.2.1" changing="false">
<artifact name="gcc" ext="tbz2" e:classifier="src"/>
</dependency>
'rev=' can be a fixed value or 'latest' or whatever.
In my build file I would like to get hold of the value of 'rev' to be uses in further work flow after resolve is run.
Is there any way to do that or read a property for this?
Use the artifactproperty task
<ivy:artifactproperty name="version.[artifact]" value="[revision]"/>
<echo message="gcc version: ${version.gcc}"/>
Related
I have a simple ant build with the following ivy dependencies:
<ivy-module version="2.0">
<info organisation="de.jflex" module="examples.simple"/>
<dependencies>
<dependency org="junit" name="junit" rev="4.12"/>
<dependency org="com.google.guava" name="guava" rev="26.0-jre"/>
<dependency org="com.google.truth" name="truth" rev="0.36"/>
</dependencies>
</ivy-module>
ant build fails with:
circular dependency found: com.google.truth#truth;0.36->com.google.testing.compile#compile-testing;0.12->com.google.truth#truth;0.35
But it's not a hard circular dependency: they depend on different versions. How do I work around this?
You are only getting a warning, which is also a default value of the circularDependencyStrategysetting. If you really want to hide this, you can set that attribute to ignore. But it looks like that even if you change this, dependecy resolution will still fail, due to unresolved com.google.gwt#gwt-user;2.8.0: com.google.gwt#gwt;2.8.0->org.sonatype.oss#oss-parent;4
I have a huge dependency which exports a number of dependencies. I wish to restrict my retriev to couple of them. The pattern is [artifact]-[revision].[ext].
How do i specify this in ivy:retrieve task call
Configurations in ivy is the mechanism for controlling groups of dependencies within ivy.
Once these configurations have been setup in your ivy file it becomes simple to retrieve them within your ANT build as follows:
<ivy:retrieve pattern="lib/[artifact].[ext]" conf="my_custom_conf"/>
Perhaps you could supply some more details of what you want to achieve and someone can demonstrate how to setup a configuration for this purpose. (I'd also recommend searching the Stackoverflow ivy tag, for other examples)
Update
If an ivy module publishes more than one artifact it's possible to restrict the dependency in your ivy file as follows:
ivy.xml
<configurations>
..
<conf name="archives" description="Configuration containing only archive files"/>
</configurations>
<dependencies>
..
<dependency org="acme" name="foo" rev="2.0" conf="archives->default">
<artifact name="a1" type="tar"/>
<artifact name="an" type="zip"/>
</dependency>
</dependencies>
Alternatively..
Look into the remote modules's ivy.xml. There may already be a configuration setup for these files, in which case it becomes a lot simpler (because it's been pre-setup)
<dependency org="acme" name="foo" rev="2.0" conf="archives->remotearchives"/>
The "conf" part of the dependency is mapping the remote configuration onto your local one.
I want to use the url resolver to download depends. The depends are JS, or XML files. So, I used:
<url name="urlresolver">
<artifact pattern="http://[organisation]/[module]-[revision].[ext]" />
</url>
And
<ivy:retrieve pattern="${build}/[module]-[revision].[ext]"/>
the file is saved in .jar extension.
It's worth digging around the following ivy docs:
Terminology
Main Concepts
Best Practices
The first problem is that your url resolver is not configured to read ivy files for the remote modules (ignoring the first recommendation, in the ivy best practices, to use an ivy file with each module). Without module meta-data ivy will assume you're attempting to download JAR files.
A second problem is that you don't appear to be using an ivy repository to store your files. The following dependency declaration:
<dependency org="yourorg" name="module1" rev="9.1"/>
would be translated into the following URL, using your current settings:
http://yourorg/module1-9.1.jar
The "org" field is designed to specify the organisational unit publishing the module, not the server hostname.
I suspect that you're not really interested in building a repository of files and just want to persuade ivy to download and cache the files? In that case I'd recommend reading the following answer which is using extra attributes on the dependency artifacts to do something similar:
Resolving XSD's using Ivy
Example
ivy.xml
<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
..
..
<dependency org="yourorg" name="yourmodule1" rev="9.1">
<artifact name="file1" e:hostname="www.server1.com" type="xml"/>
<artifact name="file2" e:hostname="www.server1.com" type="xml"/>
</dependency>
<dependency org="yourorg" name="yourmodule2" rev="9.1">
<artifact name="file3" e:hostname="www.server2.com" type="xml"/>
<artifact name="file4" e:hostname="www.server2.com" type="xml"/>
</dependency>
..
Note:
Each dependency declares the type of each artifact, plus the additional "hostname" attribute.
If the remote modules had ivy.xml, the publications section would alternatively store this artifact information.
Extra artifacts demonstrate ivy's power in enabling any sort of custom attribute meta-data.
ivysettings.xml
..
<url name="urlresolver">
<artifact pattern="http://[hostname]/files/[organisation]/[module]-[revision].[ext]" />
</url>
..
Demonstrates how the resolver makes use of both the standard attributes and the custom "hostname".
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
I'm following the Grails Mail tutorial: http://grails.org/A+simple+EmailerService and it mentions "Then copy two jar files into the application local lib: activations.jar and mail.jar.". Though I can do the manual copy, I was wondering if there's some way I could update my Ivy configuration file to do that pulling automatically instead. I'm not familiar enough with Ivy at this point to know how to look for repositories, etc..
First of all you need to install the ivy plugin:
grails install-plugin ivy
Then you can configure your ivy.xml:
<ivy-module version="2.0">
<info organisation="apache" module="hello-ivy"/>
<dependencies>
<dependency org="commons-lang" name="commons-lang" rev="2.0"/>
<dependency org="commons-cli" name="commons-cli" rev="1.0"/>
</dependencies>
</ivy-module>
Finally, invoke the grails get-dependencies command.
The jars will then be downloaded in the project's lib directory.
It depends on where you get your jars from. For info on Ivy and how it deals with dependencys see this link. http://www.ibm.com/developerworks/java/library/j-ap05068/index.html