Supporting the file protocol for the "upload" task?

[Morgan Delagrange]

Hi all,

The site claims that buildr only uses  the SFTP protocol for uploads:

   http://incubator.apache.org/buildr/packaging.html#installing_and_uploading

However I tested out the file protocol and it seems to work fine.
This would be useful for servers (like a continuous integration
server) that may have direct access to the file structure for the
repository.  Is there any reason not to support the file protocol?

If it seems like a good option, you could patch the documentation with
something like the diff below.

Thanks!
- Morgan

Index: doc/pages/packaging.textile
===================================================================
--- doc/pages/packaging.textile (revision 672348)
+++ doc/pages/packaging.textile (working copy)
@@ -508,8 +508,9 @@
  repositories.release_to = 'sftp://john:secret@release/usr/share/repo'
  }}}

-We're using the SFTP protocol, currently the only protocol Buildr
uses for
-uploads.  The URL contains the release server ("release"), path to
repository
+Currently "SFTP" and "file" are the only protocols Buildr uses for
uploads,
+and in this example we're using the SFTP protocol.
+The URL contains the release server ("release"), path to repository
  ("user/share/repo") and username/password for access.  The way SFTP
works, you
  specify the path on the release server, and give the user
permissions to create
  directories and files inside the repository.  The file system path
is different

CONFIDENTIALITY NOTE
The document(s) accompanying this e-mail transmission, if any, and the e-mail transmittal message containing information from Leapfrog Online Customer Acquisition, LLC is confidential or privileged. The information is intended to be for the use of the individual(s) or entity(ies) named on this e-mail transmission message. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is prohibited. If you have received this e-mail in error, please immediately delete this e-mail and notify us by telephone of the error.

[Assaf Arkin]

On Fri, Jun 27, 2008 at 11:30 AM, Morgan Delagrange
<mdelagrange@...> wrote:

> Hi all,
>
> The site claims that buildr only uses  the SFTP protocol for uploads:
>
>  http://incubator.apache.org/buildr/packaging.html#installing_and_uploading
>
> However I tested out the file protocol and it seems to work fine.
> This would be useful for servers (like a continuous integration
> server) that may have direct access to the file structure for the
> repository.  Is there any reason not to support the file protocol?
>
> If it seems like a good option, you could patch the documentation with
> something like the diff below.

Thanks for spotting that.  We also have HTTP uploads working, so I'm
adding a mention of both in the documentation.

Assaf

>
> Thanks!
> - Morgan
>
> Index: doc/pages/packaging.textile
> ===================================================================
> --- doc/pages/packaging.textile (revision 672348)
> +++ doc/pages/packaging.textile (working copy)
> @@ -508,8 +508,9 @@
>  repositories.release_to = 'sftp://john:secret@release/usr/share/repo'
>  }}}
>
> -We're using the SFTP protocol, currently the only protocol Buildr
> uses for
> -uploads.  The URL contains the release server ("release"), path to
> repository
> +Currently "SFTP" and "file" are the only protocols Buildr uses for
> uploads,
> +and in this example we're using the SFTP protocol.
> +The URL contains the release server ("release"), path to repository
>  ("user/share/repo") and username/password for access.  The way SFTP
> works, you
>  specify the path on the release server, and give the user
> permissions to create
>  directories and files inside the repository.  The file system path
> is different
>
> CONFIDENTIALITY NOTE
> The document(s) accompanying this e-mail transmission, if any, and the
> e-mail transmittal message containing information from Leapfrog Online
> Customer Acquisition, LLC is confidential or privileged. The information is
> intended to be for the use of the individual(s) or entity(ies) named on this
> e-mail transmission message. If you are not the intended recipient, be aware
> that any disclosure, copying, distribution or use of the contents of this
> e-mail is prohibited. If you have received this e-mail in error, please
> immediately delete this e-mail and notify us by telephone of the error.
>