ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hilton, Chris" <Chris.Hil...@zilliant.com>
Subject RE: Problem grabbing updated artifacts
Date Wed, 28 Nov 2007 21:54:59 GMT
Well, I seem to have hit upon the issue after some debugging. When I get to the offending conditional,
here are my variable values:

repLastModified:   1196271408
cacheLastModified: 1194477984933

Guess that shows why the cache version is preferred. Further debugging found that the lastModified
value for the cached version of the ivy file I'm having problems with comes from the URLConnection
class which returns the last modified time in number of milliseconds [1], whereas the parseTLine()
in the Scp class is returning last modified time in number of seconds.

For further info, I watched the above variables as I had Ivy resolve a project with dependencies
on 44 different projects. Of those, 36 performed second-to-second comparisons and 8 performed
erroneous second-to-millisecond comparisons.

I'm not sure what's causing it, but it doesn't look like the SSH resolver is reliable for
checking updated ivy files at the moment. I'll try a different resolver and see if I get better
results.

Chris

[1] http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLConnection.html#getLastModified()

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Monday, 26 November, 2007 18:52
> To: ivy-user@incubator.apache.org
> Subject: Re: Problem grabbing updated artifacts
>
> I really think the problem comes from the timestamp, the isDefault return
> true only if the module descriptor was not found and generated in memory
> by
> Ivy from the artifact only. In your case I think the problem comes from an
> incompatibility with cygwin SSH, but I won't be of much help to track the
> problem down. Try debugging with a debugger and follow step by step what's
> going on in the SSHResolver.
>
> Xavier
>
> On Nov 27, 2007 1:05 AM, Hilton, Chris <Chris.Hilton@zilliant.com> wrote:
>
> > I'm using the Cygwin SSH server. I looked through the code from your
> link
> > below to see what it expects from the SSH server and thought it might be
> a
> > problem with parseTLine() in the Scp class, but I get the following when
> I
> > run a debugging command against the SSH server:
> >
> > $ scp -p -v chilton@localhost
> > :/cygdrive/c/temp/ftp/repository/zilliant/policymg
> > t_campaignmanager_swingui/6.5.0.0/ivy.xml .
> > Executing: program /usr/bin/ssh host localhost, user chilton, command
> scp
> > -v -p
> > -f
> >
> /cygdrive/c/temp/ftp/repository/zilliant/policymgt_campaignmanager_swingui
> /6.
> > 5.0.0/ivy.xml
> > OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
> > debug1: Reading configuration data /etc/ssh_config
> > debug1: Connecting to localhost [127.0.0.1] port 22.
> > debug1: Connection established.
> > debug1: identity file /cygdrive/u/.ssh/identity type -1
> > debug1: identity file /cygdrive/u/.ssh/id_rsa type -1
> > debug1: identity file /cygdrive/u/.ssh/id_dsa type -1
> > debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
> > debug1: match: OpenSSH_4.7 pat OpenSSH*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_4.7
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: server->client aes128-cbc hmac-md5 none
> > debug1: kex: client->server aes128-cbc hmac-md5 none
> > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> > debug1: Host 'localhost' is known and matches the RSA host key.
> > debug1: Found key in /cygdrive/u/.ssh/known_hosts:3
> > debug1: ssh_rsa_verify: signature correct
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: expecting SSH2_MSG_NEWKEYS
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: SSH2_MSG_SERVICE_REQUEST sent
> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> > debug1: Authentications that can continue:
> > publickey,password,keyboard-interacti
> > ve
> > debug1: Next authentication method: publickey
> > debug1: Trying private key: /cygdrive/u/.ssh/identity
> > debug1: Trying private key: /cygdrive/u/.ssh/id_rsa
> > debug1: Trying private key: /cygdrive/u/.ssh/id_dsa
> > debug1: Next authentication method: keyboard-interactive
> > debug1: Authentications that can continue:
> > publickey,password,keyboard-interacti
> > ve
> > debug1: Next authentication method: password
> > chilton@localhost's password:
> > debug1: Authentication succeeded (password).
> > debug1: channel 0: new [client-session]
> > debug1: Entering interactive session.
> > debug1: Sending command: scp -v -p -f
> > /cygdrive/c/temp/ftp/repository/zilliant/p
> > olicymgt_campaignmanager_swingui/6.5.0.0/ivy.xml
> > Could not chdir to home directory /cygdrive/u: No such file or directory
> > Sink: T1195587575 0 1196118721 0
> > Sending file modes: C0600 1843 ivy.xml
> > Sink: C0600 1843 ivy.xml
> > ivy.xml                                       100% 1843     1.8KB/s
> > 00:00
> > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> > debug1: channel 0: free: client-session, nchannels 1
> > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.9 seconds
> > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> > debug1: Exit status 0
> >
> > You can see the "T" line above looks like what parseTLine() expects and
> it
> > has the correct last modified timestamp (a Nov. 20 date, more recent
> than
> > the Nov. 7 date in the cache). So it seems to me that either that date
> isn't
> > getting down to the "not updated" comparison you pointed out in
> > BasicResolver, or it could be the other part of the conditional
> > (!rmr.getDescriptor().isDefault()) is evaluating to true. What do you
> think?
> > Is there something I can check for that conditional part?
> >
> > Chris
> >
> > > -----Original Message-----
> > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > Sent: Wednesday, 21 November, 2007 13:01
> > > To: ivy-user@incubator.apache.org
> > > Subject: Re: Problem grabbing updated artifacts
> > >
> > > According to the code [1] and your debug trace("not updated"), Ivy
> finds
> > a
> > > last modified time stamp in the repository which is older than cache
> > one.
> > > So
> > > it seems your problem comes from the SSH repository implementation.
> > Which
> > > SSH server are you using? Maybe its a problem of incompatibility with
> > the
> > > library we use... I suggest trying with another SSH server, and maybe
> > also
> > > trying with a simple filesystem resolver to see if it's related to SSH
> > or
> > > a
> > > more general problem.
> > >
> > > Xavier
> > >
> > > [1]
> > >
> >
> https://svn.apache.org/repos/asf/incubator/ivy/core/tags/1.4.1/src/java/fr
> > > /jayasoft/ivy/resolver/BasicResolver.java
> > >
> > > On Nov 21, 2007 7:33 PM, Hilton, Chris <Chris.Hilton@zilliant.com>
> > wrote:
> > >
> > > > > Yes, this is very strange. Which version of Ivy do you use?
> > > >
> > > > 1.4.1.
> > > >
> > > > Chris
> > > >
> > >
> > >
> > >
> > > --
> > > Xavier Hanin - Independent Java Consultant
> > > http://xhab.blogspot.com/
> > > http://ant.apache.org/ivy/
> > > http://www.xoocode.org/
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

Mime
View raw message