You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Alex Boisvert (JIRA)" <ji...@apache.org> on 2010/08/19 17:01:36 UTC

[jira] Commented: (BUILDR-491) sftp download goes into infinite loop

    [ https://issues.apache.org/jira/browse/BUILDR-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900300#action_12900300 ] 

Alex Boisvert commented on BUILDR-491:
--------------------------------------

I was able to reproduce.

Issue is in buildr/core/transports.rb

  class SFTP < Generic #:nodoc:
    ...
    def read(options = {}, &block)
      ...
                while chunk = file.read(RW_CHUNK_SIZE)
                  block.call chunk
                  progress << chunk
                end

the sftp documentation (http://net-ssh.rubyforge.org/sftp/v2/api/index.html) states that fewer bytes read than RW_CHUNK_SIZE indicates EOF.


> sftp download goes into infinite loop
> -------------------------------------
>
>                 Key: BUILDR-491
>                 URL: https://issues.apache.org/jira/browse/BUILDR-491
>             Project: Buildr
>          Issue Type: Bug
>          Components: Core features
>    Affects Versions: 1.3.5
>         Environment: ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
> Buildr 1.3.5 
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Darwin 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386
>            Reporter: Ed Smiley
>
> Background:
> I originally encountered this in a complicated cross project setting where I was placing some files from one project and zipping them up as a zip file (jars and ruby scripts) and then extracting them and using them in another.  I just point this out as this affects both zip and jar archive artifacts.  As the original code was complex, I coded a much simpler version with one script to upload a jar file to a repo and another script dependent on downloading and extracting it.  I also tried a lot of alternatives which I won't report here.
> Steps to reproduce:
> 1. Create a remote repository with user/password sftp access
> 2. Create a simple script to build a jar file and run the upload task to store the artifact
> 3. Verify that the upload is successful.
> 4. Create a simple script to download the artifact and unzip it
> 5. Run it with --trace enabled
> 6. It appears to download to the wrong directory and hangs.
> Here is the data (with details anonymized to preserve my company's security) as reported to the Buildr list.
> On Wed, Aug 18, 2010 at 10:46, Ed Smiley <es...@ebrary.com> wrote:
> > I have been running into this problem when attempting to download an
> > archive
> > from a remote repository in a variety of ways as I attempted to work around
> > it.  I uploaded and verified the installation of an archive on a server
> > that
> > I set up via sftp.  When I trigger a download, it seems to want to install
> > the archive in a directory on my machine that mirrors its location on the
> > remote server, rather than installing it in my local .m2 (maven2)
> > repository.
> >
> > Rather than give a long explanation, I coded up a pair of build scripts,
> > one
> > to create and upload the archive and another to unzip the archive.  I tried
> > to use code that is very close to documentation example code, so that any
> > complexities are eliminated.  Here's the details (with security sensitive
> > details obscured.
> >
> > 1. A simple buildfile for a jar that has a single class in it.
> > ...src/main/java/org/screwloose/repotest/RepoStub.java
> >  a. the buildfile
> > VERSION_NUMBER = "1.0.0"
> > # Group identifier for your projects
> > GROUP = "repotest"
> > COPYRIGHT = ""
> > # Specify Maven 2.0 remote repositories here, like this:
> > repositories.remote << "http://www.ibiblio.org/maven2/"
> > # Specify Maven 2.0 remote repository to release to
> > repositories.release_to = 'sftp://
> > someuser:somepassword@someserver.somedomain.com/usr/share/maven2/'
> > desc "The Repotest project"
> > define "repotest" do
> >  project.version = VERSION_NUMBER
> >  project.group = GROUP
> >  manifest["Implementation-Vendor"] = COPYRIGHT
> >  package(:jar)
> > end
> >  b. running the buildfile
> > ~/somedirectory/research/repotest $ buildr upload
> > (in /somehomedirs/myusername/somedirectory/research/repotest, development)
> > Building repotest
> > Packaging repotest
> > Running integration tests...
> > Deploying packages from repotest
> > Deploying repotest:repotest:pom:1.0.0
> > Deploying repotest:repotest:jar:1.0.0
> > Completed in 13.721s
> >
> > 2. Another stub buildfile with a compile, and hence, a build, dependency on
> > downloading the jar from the remote.
> >  a. the stub
> > # Generated by Buildr 1.3.5, change to your liking
> > # Version number for this release
> > VERSION_NUMBER = "1.0.0"
> > # Group identifier for your projects
> > GROUP = "repotest"
> > COPYRIGHT = ""
> > # Specify Maven 2.0 remote repositories here, like this:
> > repositories.remote << 'sftp://
> > someuser:somepassword@someserver.somedomain.com/usr/share/maven2/'
> > repositories.remote << "http://www.ibiblio.org/maven2/"
> > desc "The Repotest Test Archive project"
> > define "testarch" do
> >  project.version = VERSION_NUMBER
> >  project.group = GROUP
> >  manifest["Implementation-Vendor"] = COPYRIGHT
> >  the_jar = artifact('repotest:repotest:jar:1.0.0')
> >  task :unzip_jar => unzip(_("target/stuff") => the_jar) do
> >     compile.with Dir[_("target/stuff/WEB-INF/lib") + "/*.jar"]
> >  end
> >  task :compile => :unzip_jar
> > end
> >
> >  b. running the test script with trace
> > ~/somedirectory/research/repotest $ buildr -f testsarc.rb --trace
> > (in /somehomedirs/myusername/somedirectory/research/repotest, development)
> > ** Invoke testarch (first_time)
> > ** Execute testarch
> > Defining task testarch:shell:jirb
> > Defining task testarch:shell:clj
> > Defining task testarch:shell:bsh
> > ** Invoke
> >
> > /somehomedirs/myusername/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar
> > (first_time, not_needed)
> > ** Invoke
> >
> > /somehomedirs/myusername/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
> > (first_time, not_needed)
> > ** Invoke
> >
> > /somehomedirs/myusername/.m2/repository/org/apache/ant/ant-trax/1.7.1/ant-trax-1.7.1.jar
> > (first_time, not_needed)
> > ** Invoke /somelibrarydir/Ruby/Gems/1.8/gems/buildr-1.3.5/lib/buildr/java
> > (first_time, not_needed)
> > Defining task shell based on shell:bsh
> > ** Invoke testarch
> > ** Invoke default (first_time)
> > ** Invoke build (first_time)
> > ** Execute build
> > Building testarch
> > ** Invoke testarch:build (first_time)
> > ** Invoke
> > /somehomedirs/myusername/somedirectory/research/repotest/target/classes
> > (first_time, not_needed)
> > ** Invoke testarch:compile (first_time, not_needed)
> > ** Invoke testarch:resources (first_time)
> > ** Execute testarch:resources
> > ** Invoke testarch:unzip_jar (first_time)
> > ** Invoke
> > /somehomedirs/myusername/somedirectory/research/repotest/target/stuff
> > (first_time)
> > ** Invoke
> >
> > /somehomedirs/myusername/.m2/repository/repotest/repotest/1.0.0/repotest-1.0.0.jar
> > (first_time)
> > ** Execute
> >
> > /somehomedirs/myusername/.m2/repository/repotest/repotest/1.0.0/repotest-1.0.0.jar
> > Downloading repotest:repotest:jar:1.0.0
> > Downloading repotest:repotest:jar:1.0.0
> > Connecting to someserver.somedomain.com
> > connected
> > Downloading to /usr/share/maven2/repotest/repotest/1.0.0/repotest-1.0.0.jar
> > [hangs for an hour or more....<===========================]
> >

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.