ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Resolving latest "integration" artifacts
Date Tue, 05 Dec 2006 23:16:59 GMT
Mmm, it's strange, what you did first should be working. Using the
changingPattern should tell ivy that your -dev revision is a changing one,
and Ivy should check for updates of your jars. So it may be a bug in Ivy...
I realize that there is only one unit test which tests the behaviour with
changing dependency, and it checks only one simple case, where there is an
ivy file. No test with no ivy file.

Ok, now let's see why even with an ivy file it doesn't work... I'm missing
some parts of your configuration, but did you update your url resolver to
add a pattern for your ivy files:
<url name="internal" changingPattern=".*-dev">
          <ivy pattern="${ivy.shared.config.root}/${
ivy.shared.config.pattern}"  />
          <artifact pattern="${ivy.shared.default.root}/${
ivy.shared.default.artifact.pattern}"  />

If you did, I don't see why Ivy do not download your just published ivy
file. Maybe you could add checkModified="true" in your ivyconf.xml, to be
sure ivy checks your ivy files for modifications. If you still have problem,
send a mail and attach your ant debug log of your resolve (what you get with
ant -d), and I'll have a look to try to understand what's going on.


On 12/5/06, John Brugge <> wrote:
> 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.
>   <resolvers>
>       <url name="internal" changingPattern=".*-dev">
>           <artifact
> pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern
> }"
> />
>       </url>
> 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
> cache.
>         If the ivy file in the repository is newer, ivy will download it,
> replace
>         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}"
> host="${repository.server}">
>           <ivy
> pattern="${ivy.shared.config.root}/${ivy.shared.config.pattern}"
> />
>           <artifact
> pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern
> }"
> />
>       </ssh>
> 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"
>                     module="my-component"
>                     revision="1.0.0-dev"
>                     status="release"
>                     publication="20061204100604"
>                     default="true"
>             />
>             <configurations>
>                     <conf name="default" visibility="public"/>
>             </configurations>
>             <publications>
>                     <artifact name="my-component" type="jar" ext="jar"
> conf="default"/>
>             </publications>
>     </ivy-module>
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message