ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xavier Hanin <xavier.ha...@gmail.com>
Subject RE: Problem grabbing updated artifacts
Date Thu, 29 Nov 2007 19:39:25 GMT

Thanks for the follow up Chris, and happy to see you now have a solution.

Xavier


Hilton, Chris wrote:
> 
> I seem to have found a good solution by publishing with a SSH resolver
> outside of my chain and setting up a URL resolver in my chain that points
> to a web server with a virtual directory to where the SSH publishing went.
> I monitored Ivy's resolution with the URL resolver and consistently get
> millisecond to millisecond comparisons for the last modified times. Not
> quite as clean as a single resolver for publishing and resolution, but
> good enough and it probably helps that I'll now keep the SSH credentials
> separate.
> 
> Chris
> 
>> -----Original Message-----
>> From: Hilton, Chris [mailto:Chris.Hilton@zilliant.com]
>> Sent: Wednesday, 28 November, 2007 15:55
>> To: ivy-user@incubator.apache.org
>> Subject: RE: Problem grabbing updated artifacts
>>
>> 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#getLas
>> tModified()
>>
>> > -----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/
> 
> 

-- 
View this message in context: http://www.nabble.com/Problem-grabbing-updated-artifacts-tf4847007.html#a14033246
Sent from the ivy-user mailing list archive at Nabble.com.


Mime
View raw message