[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Using remote zip'd repos in p2

Hi Ian,

It looks like you've come to the same conclusion we've had in the past. Zipped repositories should work in theory, and for local zips they may actually be practical. However, the performance of manipulating streams on jar: URL's is quite bad, both in speed and in-memory performance. The separation we already have been metadata, artifact index, and individual artifact jars ensures we only download what we need from the server. So, for "interactive" scenarios such as using the p2 UI, it's better to have unzipped repositories. The main value of zipped repositories is that an entire repository can be fetched as a single file from a server and then exploded on disk (for example by a script as part of an automated build).


Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

07/31/2009 07:26 PM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

P2 developer discussions <p2-dev@xxxxxxxxxxx>
Re: [p2-dev] Using remote zip'd repos in p2

I did some more testing, and It's actually worse than that nick. It turns out that each time you restart Eclipse (and look at your repository) it will re-download the entire jar.  This is going to be a problem.

In the end, if we put other files (content / artifacts) beside the jar, then why not just expand the repos on the server?  I was just thinking that if could make zip'd repos work, then this would give us an easy way to make the results of a build available to users.


On Fri, Jul 31, 2009 at 2:28 PM, Nick Boldt <nickboldt@xxxxxxxxx> wrote:
+1. Remote update site zip support would be teh axxesome.

What about if the metadata was optionally provided as a second (and
third?) downloadable jar, like md5sums are?

Thus, user inputs this into p2 UI:


p2 interprets it as:


and corrects it in the UI.

Then it fetches


cracks THAT open to reveal content.xml, artifacts.xml, and can therefore
do the whole site introspection w/o having to dl a few megs of zip first
- no more to fetch than with an unpacked update site today.

Or, if you only need one of the two metadata files (I've no idea), then
you could instead fetch:

http://eclipse.org/equinox-sdk.content.jar or equinox-sdk.artifacts.jar**



* alternate filename ideas:


("Never meta.jar I didn't like.")

** more variations:


("Your repo is ajar.")
("Close, but no cjar!")


Ian Bull wrote:
> Hi everyone,
> Do we have plans to support repos in the following form:
> jar:
> By shipping all these "zip'd repos", it seems like it would be a good
> idea to let people craft their targets (or install their software)
> directly from Eclipse without first D/L the zips first.  This appears to
> "almost work", but it looks like we set a timeout for the content.jar
> file.  If we can download the repo, crack it open, and read the
> content.jar before the timeout, then we're golden.  But if not, then all
> bets are off.
> Does anyone have thoughts on this?
> cheers,
> ian
> --
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

> ------------------------------------------------------------------------
> _______________________________________________
> p2-dev mailing list

Nick Boldt ::
Release Engineer :: Eclipse Modeling & Dash Athena
p2-dev mailing list


R. Ian Bull | EclipseSource Victoria | +1 250 477 7484

http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
p2-dev mailing list