Re: [orbit-dev] Invitation: Orbit conference call (Jan 9 11:00 AM EST)

[Eugene Kuleshov <eu@xxxxxxxx>]

 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