You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Davide Baroncelli <ba...@yahoo.com> on 2007/10/15 13:07:16 UTC
difference for "resolve" in 2.0
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 SPA-stratosfera-commons-working@wsictdb2p.xml
(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.
Re: difference for "resolve" in 2.0
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/23/07, Davide Baroncelli <ba...@yahoo.com> wrote:
>
>
> >> 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.
> >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?
>
> Hi,sorry for the late answer: I will open a jira issue, but are you sure
> this is a bug? I mean, after all in the publish task I use an explicit
> "revision" tag: should this use the "working@hostname" resolved file
> instead
> of looking for an explicit version number?
Indeed, I read that too quickly, I thought you were using pubrevision, which
should behave as you expect, but using revision attribute is supposed to do
what it does... in 2.0 :-)
Anyway, I've found a couple of other problems with 2.0, I will open separate
> issues for those ones.
Ok, thanks,
Xavier
--
> View this message in context:
> http://www.nabble.com/difference-for-%22resolve%22-in-2.0-tf4627611.html#a13362684
> Sent from the ivy-dev mailing list archive at Nabble.com.
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: difference for "resolve" in 2.0
Posted by Davide Baroncelli <ba...@yahoo.com>.
>> 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.
>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?
Hi,sorry for the late answer: I will open a jira issue, but are you sure
this is a bug? I mean, after all in the publish task I use an explicit
"revision" tag: should this use the "working@hostname" resolved file instead
of looking for an explicit version number?
Anyway, I've found a couple of other problems with 2.0, I will open separate
issues for those ones.
--
View this message in context: http://www.nabble.com/difference-for-%22resolve%22-in-2.0-tf4627611.html#a13362684
Sent from the ivy-dev mailing list archive at Nabble.com.
Re: difference for "resolve" in 2.0
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/15/07, Davide Baroncelli <ba...@yahoo.com> 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 SPA-stratosfera-commons-working@wsictdb2p.xml
>
> (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/