[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)
|
BTW, there are several components in Maven project that can be used
for resolution and downloading without enforcing any particular
descriptors or repository formats.
For instance, Wagon project provides several transport layers,
including, http, ftp, scp and maybe few others in unified API.
There is also an artifact resolver that takes artifact descriptor and
repository layout configuration and then resolve and if necessary
download artifacts/jars locally (it is using Wagon).
regards,
Eugene
Jeff McAffer wrote:
This seems like an interesting approach to implementing an OBR-like
client. Note that OBR is not a transfer protocol but rather more a
discovery and selection mechanism. It uses metadata that follows the
proposal in OSGi RFC 112 and uses that information to select and then
download the required/requested information. Related to this is an
indexing tool that generates the required metadata (David Williams has
been running that on the Callisto update site for example).
To be clear, I am not pushing OBR per se. What I like about it is
that it is repo independent, small, simple and it exists. Going
forward I hope that the Eclipse provisioning story will be expanded to
include the kinds of usecases discussed here (including the need to
accomodate various repo formats).
Did I miss something wrt the function that the ECF code provides?
Jeff
*Scott Lewis <slewis@xxxxxxxxxxxxx>*
Sent by: orbit-dev-bounces@xxxxxxxxxxx
01/10/2007 03:16 PM
Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
To
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject
Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)
Hi Jeff and all,
Jeff McAffer wrote:
couple of notes.
- OBR was just one idea. The main benefit is that it is repo agnostic
so the current orbit download site for example would serve just fine
as a repo. Similarly, an update site or maven repo would alos work...
One thought/immodest proposal: ECF is finishing up a 'filetransfer'
API (org.eclipse.ecf.filetransfer) that supports asynchronous file
retrieval. It's similar to KDE's KIO (in concept anyway). We use now
us Apache httpclient 3.0.1 for http/https (soon from Orbit) and
java.net.URLConnection for ftp, file, bittorrent (EPL impl done and
soon to be added) and any others registered via URLStreamHandlerService.
It would/will be simple to add maven repo (or other repos)...and
that's on the docket.
This API with appropriate providers could easily be used for fetching
from custom/other repositories as well and provide some isolation of
the client and UI code from the underlying transport/impl.
Scott