Re: [p2-dev] Using remote zip'd repos in p2

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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).

John

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>

To	P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject	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.

cheers,
ian

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:

http://eclipse.org/equinox-sdk.zip

p2 interprets it as:

jar:http://eclipse.org/equinox-sdk.zip!/

and corrects it in the UI.

Then it fetches

http://eclipse.org/equinox-sdk.p2.jar*

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**

Thoughts?

---

* alternate filename ideas:

equinox-sdk.mjar
equinox-sdk.meta.jar

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

** more variations:

equinox-sdk.ajar
equinox-sdk.cjar

("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:http://eclipse.org/equinox-sdk.zip!/
>
> 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
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



-- 
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com
| http://twitter.com/eclipsesource_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev