On 8 Sep 07, at 5:43 AM 8 Sep 07, Mauro Talevi wrote:
Jason van Zyl wrote:
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally
different story. I know tons of people who use file, dav, scp, and
ftp. Strictly for pulling I'm saying. And I'm not saying it will
satisfy our users, just throwing out the idea. But HTTP is pretty
much ubiquitous, handles all security concerns, easily
distributed ...
I agree that http is the most widely used and will satisfy the
majority of use cases.
But consider the following use case: a commercial product
delivering in the form of multiple artifacts, which then the user
will build upon (API level artifacts). Supporting a file://
protocol would enable the artifacts to be delivered as a repo and
would not require http access to import in the local repo.
I still think we can make tools to deal with the repository for
delivery a repository and accessing a local file://. But still for
remote, actually getting artifacts over the wire, that HTTP (the more
that I think about it) is all we really need. I think the vast
majority of users are doing HTTP(S).
Even if a product was delivered as a repo, which my last client
started working with their vendor to do, can be delivered using the
repository builder and using another tool like a repository importer.
The exporter importer could be made to work with file and http. But
for remote fetching just HTTP, and ditching things like FTP, SCP and
DAV for actually retrieving artifacts remotely.
The use case was that we had to mirror our internal repo to
another corp
network. We essentially zipped up the repo and transferred it to
their
machine (regularly and automatically via scm), which set a mirror
entry
pointing to the local fs. This had to be done this way because a
proxied
connection to our internal repo was not allowed, they needed full
copies
of the entire build in scm.
I think these tools could could probably be special tools using
Wagon, or something else like an rsync tool would be ideal.
I agree though that file:// is pretty useful. Just looking to make
the mechanism as streamlined, simple, and consistent as possible.
How is removing file:// going to simplify significantly the mechanism?
Not using Wagon, our abstraction, and directly focusing on HTTP.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
