0

We have recently introduced a common dependency in our build system which uses ivy:extends option within each individual ivy.xml. Common ivy.xml contents are as follows;

common-ivy.xml

<?xml-stylesheet type="text/xsl" href="http://repository.xyz.com/xsl/version-doc.xsl"?>
<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
    <info organisation="XYZ" branch="MAIN" module="CommonDependencies" revision="1.0.0" />

    <configurations defaultconfmapping="test->test(*);compile->compile(*);package->package(*)">
        <conf name="test" description="Test Time dependencies"/>
        <conf name="compile" description="Build Time dependencies"/>
        <conf name="package" description="Distributable dependencies" />
    </configurations>

    <dependencies>
        <dependency org="junit" name="junit" rev="4.8.2" conf="compile,test"/>
        <dependency org="apache" name="wss4j" rev="1.5.10" conf="compile,test" />
        <dependency org="spring" name="spring" rev="2.5.6" conf="compile" />
        <dependency org="apache" name="commons-pool" rev="1.5.5" conf="compile" />
        <dependency org="google" name="gtest" rev="1.5.0" conf="test" >
            <artifact name="gtest" type="" ext="zip" conf="test" />
        </dependency>
        <dependency org="NUnit" name="NUnit" rev="2.6" conf="test">
            <artifact name="NUnit" type="" ext="zip" conf="test" />
        </dependency>
        <dependency org="javax" name="javaee-api" rev="6.0" conf="compile,test" />
    </dependencies>
</ivy-module>

I have around 120 projects extending the common ivy shown above to get their dependencies as follows;

ivy.xml

<?xml-stylesheet type="text/xsl" href="http://repository.xyz.com/xsl/version-doc.xsl"?>
<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
    <info module="Module1" >
        <extends extendType="all"
                     organisation="XYZ"
                     module="CommonDependencies"
                     revision="1.0.0" />
    </info>

    <publications />

    <!-- Define Additional Dependencies Below -->
    <dependencies />
</ivy-module>

If you observe requirement is not to use location attribute of extends because this requires path resolution which makes all child project to be certain order etc. To achieve that we resolve common dependency once in start which produces resolved-*.xml into our local IVY cache and now want IVY to resolve the same for all child projects where it crashes with following messages;

Override ignored for property "ivy.buildlist.dir"
Overriding previous definition of property "ivy.version"
[ivy:buildlist] WARN: Unable to parse included ivy file ../ivy.xml: D:\Source\RTC-DS\Dev\ivy.xml (The system cannot find the file specified) in fil
e:/D:/Source/RTC-DS/ivy.xml
[ivy:buildlist] main: Checking cache for: dependency: XYZ#CommonDependencies;1.0.0 {}
[ivy:buildlist] don't use cache for XYZ#CommonDependencies;1.0.0: checkModified=true
[ivy:buildlist] don't use cache for XYZ#CommonDependencies;1.0.0: checkModified=true
[ivy:buildlist]                 tried C:\Users\sjunejo\.ivy2/publish/ivys/XYZ/CommonDependencies-1.0.0.xml
[ivy:buildlist]                 tried C:\Users\sjunejo\.ivy2/publish/XYZ/CommonDependencies/CommonDependencies-1.0.0-jar.jar
[ivy:buildlist]         publisher: no ivy file nor artifact found for XYZ#CommonDependencies;1.0.0
[ivy:buildlist] don't use cache for XYZ#CommonDependencies;1.0.0: checkModified=true
[ivy:buildlist]                 tried C:\Users\sjunejo/external/XYZ/CommonDependencies/CommonDependencies-1.0.0.jar
[ivy:buildlist]         external-local-resolver: no ivy file nor artifact found for XYZ#CommonDependencies;1.0.0
[ivy:buildlist] don't use cache for XYZ#CommonDependencies;1.0.0: checkModified=true
[ivy:buildlist]                 tried http://repository.XYZ.com/ivyrep/ivys/XYZ//CommonDependencies-1.0.0.xml
[ivy:buildlist] CLIENT ERROR: Not Found url=http://repository.XYZ.com/ivyrep/ivys/XYZ//CommonDependencies-1.0.0.xml
[ivy:buildlist]                 tried http://repository.XYZ.com/ivyrep/XYZ//CommonDependencies/CommonDependencies-1.0.0-jar.jar
[ivy:buildlist] CLIENT ERROR: Not Found url=http://repository.XYZ.com/ivyrep/XYZ//CommonDependencies/CommonDependencies-1.0.0-jar.j
ar
[ivy:buildlist]         XYZ-http-resolver: no ivy file nor artifact found for XYZ#CommonDependencies;1.0.0
[ivy:buildlist] don't use cache for XYZ#CommonDependencies;1.0.0: checkModified=true
[ivy:buildlist]                 tried http://repository.XYZgroup.com/external/XYZ/CommonDependencies/CommonDependencies-1.0.0.jar
[ivy:buildlist] CLIENT ERROR: Not Found url=http://repository.XYZgroup.com/external/XYZ/CommonDependencies/CommonDependencies-1.0.0.jar
[ivy:buildlist]         external-http-resolver: no ivy file nor artifact found for XYZ#CommonDependencies;1.0.0
[ivy:buildlist] WARN: Unable to parse included ivy file for XYZ#CommonDependencies;1.0.0

BUILD FAILED

Where I can clearly see that common dependency is successfully resolved and available in local cache.....how can I make <ivy:resolve /> look in local cache to find this...I have searched everywhere and it seems I have to use location :( attribute instead of relying in IVY cache.

Also when I remove the revision from common-dependency it get resolve as working@... which IVY 2.2.0 seems to resolve somehow and all my projects works OK but IVY 2.3.0 complains because it is trying to resolve revision=1.0.0 as defined in ivy.xml of child project and its mandatory otherwise IVY crashes straight away stating revision is a mandatory attribute for extends.

Tobias
  • 7,238
  • 10
  • 46
  • 77
SJunejo
  • 1,316
  • 4
  • 23
  • 39
  • Do you have you heart set on this approach? Open to alternatives? I'm not a fan of parent child module relationships in either Maven or Ivy. My preference is to use shared properties or dynamic revisions to capture interdependencies between modules. See related question: http://stackoverflow.com/questions/7019618/how-does-one-consolidate-version-management-in-ivy-like-parent-pom-dependencym – Mark O'Connor Aug 05 '14 at 17:55
  • No, I am open for alternatives but not sure how common properties in ivysettings would help in this context, I already have few properties defined in common settings and I have full control to define more. Just to let you know in this scenario the dependencies defined in common ivy will **never** be overridden. the space defined in individual ivy.xml for dependency is to only cater if projects has dependency on each other at build time and it seems this the best way! – SJunejo Aug 06 '14 at 08:28
  • Like I said I'm not a fan of parent child module relationships. It starts with good intentions. I just feel strongly that each module should explicitly list it's own dependencies. Ok, .... looking at your error again, I'm wondering... Have you published the parent module into your local repo? It looks like ivy is unable to resolve it at run-time. – Mark O'Connor Aug 06 '14 at 08:46
  • No I haven't published it...I resolved it like ``...do you think I should publish it instead of resolve? – SJunejo Aug 06 '14 at 09:41
  • Yes, I'm purely speculating, but I think it's looking for a module called "XYZ#CommonDependencies;1.0.0" (in order to inherit from). I'm guessing that if you first publish this parent module the resolution of the child ivy module will work. – Mark O'Connor Aug 06 '14 at 13:03

2 Answers2

0

OK there is no other way to solve this issue but to use the location attribute in extends. I have solved this issue by providing a property like location=${common.ivy.location} and declare this property in my ivy settings and it work like a charm.

This solution works with IVY 2.2, 2.3 and 2.4.

SJunejo
  • 1,316
  • 4
  • 23
  • 39
-2

Agree with SJunejo's reply. In my case I was getting this same error after moving from 2.2.0 to 2.3.0 and I was using the location attribute. I was however using a relative path. When I updated to use an absolute path, then the error went away.

EDIT: Dug down to the source level of Ivy. 2.3.0 did not work with a relative path, only an absolute one and 2.2.0 did not do property substitution for this location attribute, so had to stay with relative path for 2.2 since it would not property substitute my root path property. Kind of makes it hard to try back and forth to see if the upgrading would work :-(

Daniel Holmes
  • 342
  • 1
  • 2
  • 13
  • I used full absolute path not relative and it is currently working fine with IVY 2.3.0, but I have also tested with IVY 2.2 and 2.4 and its works OK as well. So simply switch to IVY 2.3 to be on safe side – SJunejo Sep 18 '14 at 20:48