ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave <davidcor...@gmail.com>
Subject Bad default behavior with <ivy:install>
Date Thu, 12 Jun 2008 16:22:55 GMT
Hey all,
I'm using the <ivy:install> ant task to install modules from the ibiblio
Maven 2 repo to our local shared drive repo.
However, I'm seeing (what I consider) strange behaviour.
When I run the install for the first time, the module + dependencies are
correctly copied to the shared repo.
However, if I re-run the install, Ivy crashes with the following message:
==========================
BUILD FAILED
C:\buildwork\snapshot\common\build.xml:44: The following error occurred
while executing this line:
C:\buildwork\snapshot\build\common-build-macros.xml:16: impossible to
install pmd#pmd;4.2.2: java.io.IOException: file copy not done from
C:\Documents and Settings\dc2\.ivy2\cache\pmd\pmd\jars\pmd
-4.2.2.jar to \\abate\data\build_lib\Ivy\pmd\pmd\4.2.2.part\pmd.jar:
destination probably already exists and overwrite is false
==========================
Now I understand that the destination exists, and overwrite equals false,
but surely there should be an option for the destination to exist, and the
install task to realise this and simply skip the actual physical copying
without having to fail the build?

There are 3 scenarios:
Install without over-write - Currently the build fails with this
Install with over-write - Build will continue but with unnecessary overhead
of re-copying the same files every time the install task is called
Install without overwrite if modules exists in destination repo - This
basically means if the resolved modules are already in the destination repo
and we don't want to over-write them, the build should not fail.

At present you can set the "haltonfailure" property, but this is to halt the
build if there are issues with the resolve part (which I can understand) as
opposed to issues with the install part (copying), if you understand me.

Surely we can add another attribute "haltonModuleExist" failure to cover
such situations. If the new attribute is set to true, the behaviour will be
as it is currently. If set to false, the build will continue if the files
already exist in the destination repo.

Perhaps this has been debated before.

Any thoughts/comments?

Regards,
Dave

-- 
There are 10 types of people in the world.
Those who understand binary and those who do not.

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