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

[jira] Created: (BUILDR-491) Unable to install and unzip artifact from remote repository

Unable to install and unzip artifact from remote repository
-----------------------------------------------------------

                 Key: BUILDR-491
                 URL: https://issues.apache.org/jira/browse/BUILDR-491
             Project: Buildr
          Issue Type: Bug
          Components: Dependency management
    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.


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

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/BUILDR-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Boisvert resolved BUILDR-491.
----------------------------------

    Fix Version/s: 1.4.2
       Resolution: Fixed

Fixed.

Sending        CHANGELOG
Sending        lib/buildr/core/transports.rb
Transmitting file data ..
Committed revision 987180.


> 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
>            Assignee: Alex Boisvert
>             Fix For: 1.4.2
>
>
> 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.


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

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/BUILDR-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Boisvert reassigned BUILDR-491:
------------------------------------

    Assignee: Alex Boisvert

> 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
>            Assignee: Alex Boisvert
>             Fix For: 1.4.2
>
>
> 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.


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

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
    [ 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.


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

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/BUILDR-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Boisvert updated BUILDR-491:
---------------------------------

        Summary: sftp download goes into infinite loop  (was: Unable to install and unzip artifact from remote repository)
    Component/s: Core features
                     (was: Dependency management)

> 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.


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

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BUILDR-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902228#action_12902228 ] 

Hudson commented on BUILDR-491:
-------------------------------

Integrated in Buildr-ci-build #104 (See [https://hudson.apache.org/hudson/job/Buildr-ci-build/104/])
    

> 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
>            Assignee: Alex Boisvert
>             Fix For: 1.4.2
>
>
> 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.