ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Problems with cache resolution
Date Tue, 09 Oct 2007 09:42:29 GMT
On 10/9/07, Andy Piper <> wrote:
> At 06:28 09/10/2007, Xavier Hanin wrote:
> >I'm in favor of considering one version as sealed, and this is the
> default
> >in Ivy. But Ivy also supports two kinds of change in a version:
> >- change of the module metadata (an updated ivy file), to deal with that
> you
> >have to use checkModified="true"
> >- change of module artifacts (this is what you want), this is what is
> called
> >a changing revision in Ivy, and you need to tell it to Ivy in one of the
> two
> >options for that:
> >   + use changing="true" when you declare your dependency on the module
> Where does this go? I can find zero documentation on this attribute

On the dependency declaration:
<dependency org="foo" name="bar" rev="2.0" changing="true" />

>   + use a changingPattern on your resolver in which the module is
> published.
> >If all your revisions are changing, you can use changingPattern="*"
> Ok so using this seems to work! Do you have an example, its not clear
> from the docs how exactly it is trying to match a "revision".

It works in pair with changingMatcher (documented just below changingPattern

The matcher concept is documented here:

>Note that before considering an artifact might have changed Ivy first
> checks
> >if the module publication date has changed, so it's important to publish
> a
> >new ivy file with at least the publication date changed.
> Ok, looks like this happens by default

Yes, if you use the publish task :-)  If you copy artifacts by hand you may
wonder why Ivy don't pick them up.

>Could you tweak your settings or your publishing strategy accordingly and
> >tell us if you still have a problem?
> Looks good.
> Incidentally I am happy to augment the documentation with editorial
> content if it would help.

Sure it would help! Documentation contribution is always welcome!

The docs are better than maven (not
> particularly hard), but still missing a lot of important detail.

Agreed. IMO the reference doc is not too bad even though it lacks some
details and cross references, the worst part is introduction and tutorials
which haven't really evolved to reflect some features introduced in recent
Ivy versions.


> andy
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.

Xavier Hanin - Independent Java Consultant

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