Closed GoogleCodeExporter closed 9 years ago
I've found a workaround for this.
If you set binaryDiff="false" in your ivysettings.xml file then it seems to
work.
Original comment by kevinsca...@gmail.com
on 8 Apr 2010 at 10:46
I'm a bit confused - you mention hibernate as the artifact you are trying to
retrieve
and yet the error occurs on commons-collections?
Also, I've never used install from IvySvn, we always just use publish and
retrieve.
In fact, I've never used Ivy install at all so I'm not sure what this involves
and
what changes would need to be made to IvySvn to support that.
Original comment by massdosage
on 8 Apr 2010 at 2:57
The error occurs, when the dependencies of the "primary target" are handled. Of
course they should be also installed into the repository. I think the check for
the version number is applied to the wrong thing. The fact that the two version
numbers are similar (but not equal) hides this fact for a while.
Have you tried the attached zip? It is a self contained demonstration of the
bug.
Original comment by ashei...@gmail.com
on 15 Jun 2010 at 8:59
I found a solution for this problem and some more problems:
1) When I use a buildfile for installing MULTIPLE modules in one run I get
accumulating messages like
[ivy:install] Overwrite set to false, ignoring
org.apache.commons/commons-beanutils/1.8.0/commons-beanutils-core-jar.jar
But these files where the modules installed before the module which emits this
message.
2) The log messages of EVERY svn commit contains the same text - that of the
first commit.
I problem is, that publishTransaction is reused for more than one transaction
and that stuff keeps accumulating there.
The solution for my problem(s) is the attached patch file. I hope, it gets
integrated soon into the next release :-)
Original comment by ashei...@gmail.com
on 25 Sep 2010 at 2:01
Attachments:
Sorry it's taken me so long to look at this.
I have never run into this problem (we never do ivy installs) so I find it hard
to comment. Your patch looks reasonable and if it fixes things for you and
doesn't break any existing functionality then I'm happy to add it. I've just
re-run all the existing unit tests with your patch and they ran fine so I have
committed it, see http://code.google.com/p/ivysvn/source/detail?r=250.
I'm assuming you're happy to have your code included and released under the
Apache 2.0 license?
I'm working on a 2.2.0 release at the moment so will do some more testing
before this goes out in an official release. In the meantime it would be
greatly appreciated if you could build yourself a version of IvySvn using the
latest trunk and see if this resolves your issue. I can also send you a jar
file of the latest trunk if that's easier for you.
If you felt like writing a unit test in the IvySvn source to reproduce this
that would be amazing but no sweat if you don't have the time.
Original comment by massdosage
on 18 Nov 2010 at 3:27
I had no problem waiting, since I built and used a patched version. But I have
checked with the last revision (r252) and it also works for me as expected.
The Apache 2.0 license (or later) is OK for me.
Regarding the unit test: I think, I'll skip this one for now ;-)
Original comment by ashei...@gmail.com
on 19 Nov 2010 at 7:00
OK, good to know, this will go out in the next version of IvySvn then.
Original comment by massdosage
on 23 Nov 2010 at 9:30
I had the same problem. The fix works for me. Thanks.
Original comment by t...@windyroad.org
on 16 Mar 2011 at 11:37
Original issue reported on code.google.com by
ashei...@gmail.com
on 22 Sep 2009 at 4:58Attachments: