<ivy-module version="1.0"> Vs <ivy-module version="2.0">
Does any one can please list me the differences between Ivy version 1 and version 2. My system
is would like to know when should i decide to upgrade to version 2.
Related
Can anybody give me a hint on how to use nested artifact (and artifacts) elements for publishing modules use the ivy ant task. Unfortunately the official documentation does not specify how to use the attributes.
http://ant.apache.org/ivy/history/latest-milestone/use/publish.html
Maybe there is some documentation or some examples that I could not find?
I am aware of the artifact element in ivy.xml files. this is NOT what this question is about.
Does this answer to this question help?
Issues using ivy:publish task
The nested "artifact" elements in the publish task are used to identify the location(s) of the artifacts you've specified as to be published by your module.
So, for example, let's say your module publishes two files:
<ivy-module version="2.0">
<info organisation="someorganisation" module="myapp"/>
<publications>
<artifact name="myapp" type="jar"/>
<artifact name="license" type="txt"/>
</publications>
..
Your publish task might need to source these files from two different locations within the build workspace:
<ivy:publish resolver="${publish.resolver}" pubrevision="${publish.revision}" status="${publish.status}">
<artifacts pattern="${build.dir}/[artifact].[ext]"/>
<artifacts pattern="${src.dir}/licenses/[organisation]/[artifact].[ext]"/>
</ivy:publish>
Is there a way to build a Grails Plugin and deploy the artifacts to the local Ivy repository?
With Maven, I would do this:
mvn install
Use the ivy publish task
<ivy:publish resolver="local" pubrevision="1.0">
<artifacts pattern="build/[artifact].[ext]" />
</ivy:publish>
Note 1
Your ivy file must list the artifacts you plan to publish
<ivy-module version="2.0">
<info organisation="myorg" module="mymodule"/>
<publications>
<artifact name="mymodule" type="zip"/>
</publications>
</ivy-module>
Maven derives this information from the module declaration in the POM file. One of the advantages of using ivy is that you can publish more than one artifact.
Note 2
The ivy local repository is located in the following location by default:
${user.dir}/.ivy2/local
You can of course create your own custom repositories by declaring alternative resolvers in you settings file
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
I have a problem with a build where I have to resolve non-standard artifacts through Apache Ivy.
Problem:
I have dependencies on two artifacts (a.jar and a-lib.jar).
The two dependencies come only as part of a single installer (a_installer.jar).
The installer can be downloaded, the embedded artifacts themselves not.
It's possible to manipulate the installer to unpack the needed dependencies.
Requirements:
I have to resolve/download the artifacts during the build (I cannot keep the installer or the extracted artifacts with my code).
I cannot use a repository to store the extracted artifacts.
Subclassing/Extending Ivy/whatever is perfectly fine.
Has anyone solved a similar problem, or some helpful information to share?
Or maybe I'm approaching the problem in the wrong way? From what I found so far on the web, people seem to use Ivy just to download files and post-process them manually (with Ant/whatever) after the fact, and not actually resolving more complicated dependencies within Ivy.
Thanks
PS: I don't care whether the installer is also put into the ivy download cache, but I would like to download the installer only one time (and not for both dependencies).
The problem with a call to "ivy:retrieve" is that you need to also add an "artifact" tag in your ivy.xml (complete with URL) in order to retrieve a dependency not found in a Maven respository...
I don't like this for two reasons
The ivy.xml should just declare your dependencies, not their locations.
Need additonal custom logic in the build.xml to handle the 3rd party package
Ideally it should be your repository settings that decide how to download the various jars, that is why I like the packager resolver. Even if the library I want is not in Maven, I can configure ivy to handle it.
The following is an example of turning the jreleaseinfo project into an ivy dependency (hosted in sourceforge, I couldn't find it in Maven)
ivy.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="ivy_packager"/>
<dependencies>
<dependency org="ch.oscg" name="jreleaseinfo" rev="1.3.0"/>
</dependencies>
</ivy-module>
Declare two resolvers. Default is Maven2, the other is a packager configured to look locally for instructions. (See also the Ivy Roundup project)
ivysettings.xml
<ivysettings>
<settings defaultResolver="maven2"/>
<resolvers>
<ibiblio name="maven2" m2compatible="true"/>
<packager name="repackage" buildRoot="${user.home}/.ivy2/packager/build" resourceCache="${user.home}/.ivy2/packager/cache">
<ivy pattern="file:///${basedir}/repository/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact pattern="file:///${basedir}/repository/[organisation]/[module]/[revision]/packager.xml"/>
</packager>
</resolvers>
<modules>
<module organisation="ch.oscg" name="jreleaseinfo" resolver="repackage"/>
</modules>
</ivysettings>
The magic is containing in the "packager" file. At resolve time this will be used to generate an ANT script that both downloads and extracts the required jars.
(No need to put this logic into your build.xml)
repository/ch.oscg/jreleaseinfo/1.3.0/packager.xml
<packager-module version="1.0">
<property name="name" value="${ivy.packager.module}"/>
<property name="version" value="${ivy.packager.revision}"/>
<property name="zipname" value="${name}-${version}"/>
<resource dest="archive" url="http://sourceforge.net/projects/jreleaseinfo/files/jreleaseinfo/jreleaseinfo%201.3.0/jreleaseinfo-1.3.0.zip/download" sha1="9386d92758e627d04c2480b820731fd538b13a3f" type="zip"/>
<build>
<move file="archive/${zipname}/${zipname}.jar" tofile="artifacts/jars/${name}.jar"/>
</build>
</packager-module>
To reduce the number of files I omitted the module's ivy.xml. This appears to be optional unless you want to declare it's licence and other attributes that should be present in a public repository.
I think this is very straightforward: 'ivy:retrieve' a_installer and then unzip a.j and a-lib into your lib directory (or wherever you want it). This should be easily to do with ant?
I have to wonder if there is some complication you haven't mentioned that prevents you from doing this.