On 10/15/07, Davide Baroncelli <[EMAIL PROTECTED]> wrote:
>
> Hi all, I am trying to replace ivy 1.4.1 with the 2.0 alpha 2 and found
> something which revealed a little bit difficult to understand: I just want
> to remark it here so that anyone trying to do the same thing in the future
> doesn't get stuck as I was.
>
> My problem was with "publish": I was trying to publish a new build without
> changing the version number (I had to add 'overwrite="true"'): everything
> worked until I deleted the cache that I had probably generated with 1.4.1.
> At that moment I started having this error:
>
> BUILD FAILED
> c:\stratosfera\commons\buildsystem\build-ivy.xml:65: impossible to publish
> artifacts for [ stratosfera SPA | stratosfera-commons | 1.0.0017 ]: [
> stratosfera SPA | stratosfera-commons | 1.0.0017 ]: java.lang.Ill
> egalStateException: ivy file not found in cache for [ stratosfera SPA |
> stratosfera-commons | 1.0.0017 ]: please resolve dependencies before
> delivering (c:\stratosfera\commons\buildsystem\cfg\..\ivy-cache\r
> esolved-stratosfera SPA-stratosfera-commons-1.0.0017.xml)
>
> Looking in the cache dir revealed that the file was indeed missing, but
> there was something called
>
> resolved-stratosfera [EMAIL PROTECTED]
>
> (wsictdb2p is my pc's name).
>
> After a while I realized that there must be a difference in how the
> resolve task works. I previously used it like this:
>
> <ivy-resolve conf="${ivy.resolve.sequence}"/>
>
> and this did work in 1.4.1. Apparently in 2.0 if not using the revision
> number like this:
>
> <ivy-resolve conf="${ivy.resolve.sequence}" revision="${
> version.number.full}"/>
>
> a default version number is generated by default and a subsequent call to
> the publish task like this:
>
> <ivy-publish artifactspattern="${dir.build.packages
> }/[artifact].[ext]"
> resolver="projects" revision="${version.number.full}"
> status="release" forcedeliver="true" overwrite="${ivy.publish.overwrite
> }"/>
>
> fails because the "resolved" file can not be found for the right revision.
>
> Adding the "revision" attribute to the "resolve" task solves the problem,
> though.
Thanks for sharing this with the community. I think we can consider that as
a bug, indeed it wasn't our intent to make the use of a revision when
calling resolve mandatory to be able to later call publish. The file you
see in your cache is normal, what is surprising is that during publish it
attempts to use a file with the revision 1.0.0017 instead of
working@<hostname> which is the default revision when no one is provided.
Could you open a JIRA issue for that?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
