Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » p2 (provisional) API questions
p2 (provisional) API questions [message #120742] Wed, 05 November 2008 09:07 Go to next message
Remy Suen is currently offline Remy SuenFriend
Messages: 462
Registered: July 2009
Senior Member
p2 (provisional) API questions go here, right?

1. Is it expected that the internal stuff will stay internal and the
internal.provisional stuff will be the one that'll become Eclipse-ready
for 3.5 (while still acknowledging that they may change between M releases)?

2. I presume the IARepository implementation is supposed to return an
array of IAKs via getArtifactKeys(), then they'll be queried for their
IADs through the getArtifactDesctipor(IAK) method, but where are the
IARequests coming from? Are we expected to implement our own IARM for
creating these IARequest instances? Where am I supposed to wire it with
my own IARepository and ARepositoryFactory instances?

3. How is it determined whether your IARepository implementation will
have getArtifact, getRawArtifact, getArtifacts, and/or getOutputStream
called? I only seem to be seeing getArtifacts invoked.

4. An IARequest doesn't have much and the IAK doesn't have much either.
When getArtifacts is invoked, are we supposed to just downcast to our
own IARequest implementations? Can we assume the IARequest array will be
what we created ourselves (through implementing IARM or otherwise...)? I
know there's an abstract ARequest class with an abstract perform(IPM)
method, but the ARequest is an internal class whereas the IARequest is a
provisional interface, will the ARequest class become API? I do see that
ARequest's constructor has a "// TODO do we need to make this
configurable? for now set default request handler to ECF" comment though
I'm not entirely sure what that's supposed to mean and whether that is
related to the perform(IPM) method or not.

Regards,
Remy
Re: p2 (provisional) API questions [message #120993 is a reply to message #120742] Tue, 11 November 2008 00:53 Go to previous message
Eclipse UserFriend
Originally posted by: eclipseng.arthorne.com

Hi Remy, see below for some answers.

Remy Chi Jian Suen wrote:
> p2 (provisional) API questions go here, right?
>
> 1. Is it expected that the internal stuff will stay internal and the
> internal.provisional stuff will be the one that'll become Eclipse-ready
> for 3.5 (while still acknowledging that they may change between M
> releases)?

The first part is right - the stuff that doesn't have
"internal.provisional" will stay internal. Some portion of the
internal.provisional packages may graduate in the 3.5 release, but we're
not sure at this point how much of it will be mature. In any case the
internal.provisional packages are packages that we hope to graduate in
real API form at some point in the future.
>
> 2. I presume the IARepository implementation is supposed to return an
> array of IAKs via getArtifactKeys(), then they'll be queried for their
> IADs through the getArtifactDesctipor(IAK) method, but where are the
> IARequests coming from? Are we expected to implement our own IARM for
> creating these IARequest instances? Where am I supposed to wire it with
> my own IARepository and ARepositoryFactory instances?
>
> 3. How is it determined whether your IARepository implementation will
> have getArtifact, getRawArtifact, getArtifacts, and/or getOutputStream
> called? I only seem to be seeing getArtifacts invoked.

The flow here is currently quite complicated, and would hopefully become
simpler if it became real API. Currently getArtifacts is called. You
need to set the source repository on the request
(ArtifactRequest#setSourceRepository), and then call
ArtifactRequest#perform. This in turn will call getArtifact(descriptor,
outputStream, monitor) on your artifact repository class. This is the
method that would actually perform the transfer.

>
> 4. An IARequest doesn't have much and the IAK doesn't have much either.
> When getArtifacts is invoked, are we supposed to just downcast to our
> own IARequest implementations? Can we assume the IARequest array will be
> what we created ourselves (through implementing IARM or otherwise...)? I
> know there's an abstract ARequest class with an abstract perform(IPM)
> method, but the ARequest is an internal class whereas the IARequest is a
> provisional interface, will the ARequest class become API? I do see that
> ARequest's constructor has a "// TODO do we need to make this
> configurable? for now set default request handler to ECF" comment though
> I'm not entirely sure what that's supposed to mean and whether that is
> related to the perform(IPM) method or not.

There are some legacy bits in here from an earlier form of the
implementation. We previously had several varieties of artifact
requests, but today we only have one: MirrorRequest. Thus this
abstraction is no longer particularly useful and could probably be
removed. The other abstraction we had was a pluggable "request handler"
that abstracted out the transport logic. After moving to ECF we no
longer needed this because ECF already has pluggable transports.

I heard or read somewhere that you were trying to create a bittorrent
implementation of a repository. To do this, you shouldn't have to
implement an artifact repository type at all. The default artifact
repository (SimpleArtifactRepository) uses ECF, so you should be able to
create a simple artifact repository with a bittorrent:// URL format and
ECF will take care of the rest... This is only possible in 3.5 M3 or
later since we previously used the URL class which required a protocol
handler to be registered. Now we use URI so you can create a
bittorrent://whatever URI.

John
--
Previous Topic:Questions on p2.director
Next Topic:P2 profileRegistry gigantic size
Goto Forum:
  


Current Time: Tue Mar 19 09:04:02 GMT 2024

Powered by FUDForum. Page generated in 0.01648 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top