ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Brugge" <>
Subject Resolving latest "integration" artifacts
Date Tue, 05 Dec 2006 20:51:34 GMT
I am trying to get Ivy to recognize updated "integration" releases of JAR
files in our repository, and am not having much luck. I am new to Ivy, so
I may well be missing some core concept or misusing some features. Any
tips are appreciated.

I am running Ivy 1.4.1 with JDK on a Linux box (Fedora Core 5),
using Ant 1.6.5.

We have a repository set up on another server that is available via http.
This repository, however, does not have Ivy configuration files published
to it, since it was set up long before Ivy came in to the picture. Its
structure, though, is compatible, and I can resolve normal dependencies
well. The problem I have is that after I publish a new
"integration"/snapshot release of a module, when I run a resolve from
another project that depends on this component the resolve doesn't seem to
notice that it has changed and needs to be updated in the cache.

Let's say the updated artifact I publish is called "my-component-1.0.0-dev".
Since the standard naming convention for integration releases here is
"-dev" at the end, I tried to add this to the URL resolver configuration.

      <url name="internal" changingPattern=".*-dev">

When I then run an <ivy:resolve> and <ivy:retrieve> from another project
that declares "my-component-1.0.0-dev" as a dependency, Ivy is not
downloading this new release. The Ant output tells me it did nothing, and
when I check the ~/.ivy/cache contents, it still has the old version of
the artifact.

I also tried adding an explicit notice to the dependency for this module,
but that did not work either.

    <dependency org="inat3" name="my-component" rev="1.0.0-dev"
            changing="true" conf="default" />

I then went and searched more of the Ivy docs and forums, and found some
more information on the "changing" attribute.

        "changing: Indicates this dependency may be updated in the repository
        without a revision change. Hence, ivy will always check the timestamp
        of the ivy file in the repository and compare to what is in the
        If the ivy file in the repository is newer, ivy will download it,
        it in the cache, and check the publication date explicitly written in
        the file. If this publication date is newer, then ivy will
download all
        artifacts of this module and replace them in cache."

Since I wasn't originally using Ivy to publish a module config for
my-component, I went and added one, along with an ssh-resolver to be used
simply to upload the JAR.

      <!-- This resolver is only used to publish, not download -->
      <ssh name="internal-publisher" user="${build.ul.userid}"

That worked fine, and it told me that it published the ivy file along with
the JAR file. When I tried the <ivy:resolve> again for the project that
depends on this module, it still refused to download the JAR. The ivy file
was retrieved, and it has the correct date of the JAR artifact, but it
didn't download it.

    <ivy-module version="1.0">
            <info organisation="inat3"
                    <conf name="default" visibility="public"/>
                    <artifact name="my-component" type="jar" ext="jar"

What I noticed here is that the module config in my cache is not the one
that I defined for the module. Obviously I'm not publishing my ivy.xml
properly with the JAR artifact, but I realize that I'm not clear on just
how to do that from the documentation.

I realize that there is more than one question in here, and I apologize
for rambling. Perhaps the issue boils down to something like this: "How
should I set up publishing the artifact of a module that is going to be of
"integration" status? And then how do I configure a resolver in another
project that depends on this module so that it will get the latest
integration build?"

thanks again for any tips or pointers. I can provide more details on my
Ivy files if that's needed.

John Brugge

View raw message