You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by dtayl <dt...@stanford.edu> on 2007/05/23 09:55:24 UTC

Executable corrupted when delivered

Hi -

In our build system, we depend on Unix shared libraries and ELF
executables, both from legacy C code, in addition to the usual artifacts
of the Java world. For consistency, I like managing everything with Ivy
(thanks Xavier!).

Although the shared libraries work fine, the executable gets corrupted
when delivered. The executable in the repository is ok, the executable
downloaded to the cache is the same, but the executable delivered from
the cache is different. To work around this in the build, I added a
post-install step to overwrite the delivered executable with the
executable from the cache, which works. And we've started a project to
replace the legacy modules with Java modules. So there's no urgent need
for a fix. But I'd like to know if I'm doing something wrong to cause
this. In the Ivy file, I assign a type and extension of 'bin', and a
filesystem resolver is used. We're still at Ivy version 1.3+. Any clues?

thanks,
david








Re: Re: Executable corrupted when delivered

Posted by dtayl <dt...@stanford.edu>.
Xavier Hanin wrote:
> Hi David,
> 
> Nice to here from you!

Hi Xavier! My emails to you must seem like the ones I get from my son in
college: they only come when there's a problem. ;-)

> 
> The problem you describe seems very strange to me. You say that the
> download
> to the cache is going well, and it's only the copy to the delivery
> destination which is causing problem, right? 

That's correct. It's very strange to me also. It took days to track down
because, with our successful heavy use of Ivy, no one suspected corruption.

> How do you do this last
> copy? -
> I should know probably, but it's been a long time since my last visit at
> Stanford :-) -
>

Hope this looks familiar:

>     <!-- **********************************************************
>             IVY RETRIEVE
>          ********************************************************** -->
>     <target name="do-retrieve-install-files" depends="ivy-configure, select-vers
> ion">
>         <!-- use ivy to download zip containing resources necessary for the inst
> allation:
>              install properties, configurations files, jsps, htmls, ... dependin
> g on the application type
>             -->
>         <ivy:retrieve organisation="${ivy.organisation}"
>                                   module="${module.name}"
>                                           revision="${module.version}"
>                                           inline="true"
>                       conf="install"
>                       pattern="${basedir}/[artifact].[ext]" />
>     </target>

In the case of a web app, Ivy downloads the zip for the web app, along
with a zip for shared web_configuration module. The executables that are
getting corrupted are in a module (called "netevent_post") specified as
a dependency in the ivy file of the web_configuration module. Here's
part of the output of an install:

do-retrieve-install-files:
[ivy:retrieve] :: resolving dependencies :: [
registry|authority_manager-caller | HEAD | working ]
[ivy:retrieve]  confs: [install]
[ivy:retrieve]  found [ registry | authority_manager | HEAD |
20070523164045-integration ] in integration
[ivy:retrieve]  found [ registry | web_configuration | HEAD |
20070522171347-release ] in release
[ivy:retrieve]  found [ registry | netevent_post | HEAD | 1.0 ] in release
[ivy:retrieve] downloading
path-to-ivyrepo/authority_manager-install-20070523164045-integration.zip ...
[ivy:retrieve] ..................... (159kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve]  [SUCCESSFUL ] [ registry | authority_manager | HEAD |
20070523164045-integration ]/authority_manager-install.zip[install] (198ms)
[ivy:retrieve] downloading
path-to-ivyrepo/web_configuration/HEAD/20070522171347-release/web_configuration-install-20070522171347-release.zip
...
[ivy:retrieve] ... (15kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve]  [SUCCESSFUL ] [ registry | web_configuration | HEAD |
20070522171347-release ]/web_configuration-install.zip[install] (40ms)
[ivy:retrieve] downloading
path-to-ivyrepo/netevent_post/HEAD/1.0/TEST_netevent_post_events-1.0.bin ...
[ivy:retrieve]
.................................................................
................................................................................
................................... (1431kB)
[ivy:retrieve]  [SUCCESSFUL ] [ registry | netevent_post | HEAD | 1.0
]/TEST_netevent_post_events.bin[bin] (372ms)


Three more executables are downloaded. Here's the resolution report:

[ivy:retrieve] :: resolution report ::
[ivy:retrieve]
----------------------------------------------------------------
-----
[ivy:retrieve]  |                  |            modules            ||
artifact
s   |
[ivy:retrieve]  |       conf       | number| search|dwnlded|evicted||
number|dwn
lded|
[ivy:retrieve]
----------------------------------------------------------------
-----
[ivy:retrieve]  |      install     |   3   |   3   |   0   |   0   ||
6   |
6   |
[ivy:retrieve]
----------------------------------------------------------------
-----
[ivy:retrieve] :: retrieving :: [ registry | authority_manager-caller ]
[ivy:retrieve]  confs: [install]
[ivy:retrieve]  6 artifacts copied, 0 already retrieved

So everything looks fine, but...it's not.

> What it is weird is that we use the same copy algorithm everywhere, so I
> don't understand why one would fail and not the other. The only 'artifacts'
> we modify sometimes are module descriptors (ivy files in your case).

Bummer. I was hoping you'd tell me I'm doing something obviously
brain-dead...I'll try retrieving other executables and see if the
behavior is consistent.

thanks,
david

Re: Executable corrupted when delivered

Posted by Xavier Hanin <xa...@gmail.com>.
Hi David,

Nice to here from you!

The problem you describe seems very strange to me. You say that the download
to the cache is going well, and it's only the copy to the delivery
destination which is causing problem, right? How do you do this last copy? -
I should know probably, but it's been a long time since my last visit at
Stanford :-) -

What it is weird is that we use the same copy algorithm everywhere, so I
don't understand why one would fail and not the other. The only 'artifacts'
we modify sometimes are module descriptors (ivy files in your case).

Xavier

On 5/23/07, dtayl <dt...@stanford.edu> wrote:
>
> Hi -
>
> In our build system, we depend on Unix shared libraries and ELF
> executables, both from legacy C code, in addition to the usual artifacts
> of the Java world. For consistency, I like managing everything with Ivy
> (thanks Xavier!).
>
> Although the shared libraries work fine, the executable gets corrupted
> when delivered. The executable in the repository is ok, the executable
> downloaded to the cache is the same, but the executable delivered from
> the cache is different. To work around this in the build, I added a
> post-install step to overwrite the delivered executable with the
> executable from the cache, which works. And we've started a project to
> replace the legacy modules with Java modules. So there's no urgent need
> for a fix. But I'd like to know if I'm doing something wrong to cause
> this. In the Ivy file, I assign a type and extension of 'bin', and a
> filesystem resolver is used. We're still at Ivy version 1.3+. Any clues?
>
> thanks,
> david
>
>
>
>
>
>
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/