Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Fw: [cross-project-issues-dev] Producing downloadable p2 repositories

Please add this issue to the next weekly call. Thx

Inactive hide details for Susan Franklin McCourt ---02/10/2009 05:40:25 PM---If this is the recommended distribution by us, theSusan Franklin McCourt ---02/10/2009 05:40:25 PM---If this is the recommended distribution by us, then we need to ensure we get our disconnected mode p


From:

Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>

To:

p2-dev@xxxxxxxxxxx

Date:

02/10/2009 05:40 PM

Subject:

[p2-dev] Fw: [cross-project-issues-dev] Producing downloadable p2 repositories




If this is the recommended distribution by us, then we need to ensure we get our disconnected mode problems solved.
People are used to downloading the zips and dealing with them later. If they are disconnected when they are ready to work with the downloaded site, then we have troubles.

(
https://bugs.eclipse.org/bugs/show_bug.cgi?id=263593)

I opened

https://bugs.eclipse.org/bugs/show_bug.cgi?id=264437

to discuss a repo-manager based solution. Otherwise we rely on clients to get it right via repo flags and provisioning contexts (multiple places).

susan

----- Forwarded by Susan Franklin McCourt/Beaverton/IBM on 02/10/2009 02:36 PM -----

                  John Arthorne <John_Arthorne@xxxxxxxxxx>
                  Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

                  02/10/2009 02:28 PM
                  Please respond to Cross project issues



To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc:
Subject: Re: [cross-project-issues-dev] Producing downloadable p2 repositories



Replacing the existing zips (that are missing metadata) is certainly the goal. In reality I suspect we couldn't replace them overnight without breaking someone. What we plan to do in the Eclipse project is introduce the zipped repository, and then phase out the old zips as soon as possible (as soon as we are confident doing so won't break our consumers).



Steve Francisco/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

02/10/2009 12:02 PM


Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] Producing downloadable p2 repositories





If a project produces a zipped p2 repository would that remove the need to produce the current zip format entirely? That is, would anything not be possible with zipped p2 repositories that is possible with the traditional zips?


_______________________________

Steve Francisco

IBM Rational, Canada Lab, Toronto
IES Technical Lead
cisco@xxxxxxxxxx 905-413-3684 TL:969
John Arthorne/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

02/10/2009 09:48 AM


Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
To
cross-project-issues-dev@xxxxxxxxxxx
cc
Subject
[cross-project-issues-dev] Producing downloadable p2 repositories









If you are responsible for your project's builds and packaging, please read on!


As you all know, providing update sites that include p2 metadata is a "must do" for the Galileo release. Now that everyone is producing this metadata, the obvious question that arises is how do people building products and packages consume this metadata? Everyone is accustomed to consuming Eclipse project output in the convenient form of zip files:


* zips are easily replicated to company mirrors, which reduces bandwidth costs for both producers and consumers

* zips are a reliable and consistent input for builds. If you keep the input zips around, you can reproduce an old build easily and reliably

* power users can hack together applications by unzipping various zips into the Eclipse dropins folder


However, there are also numerous advantages to consuming project output in the form of p2 repositories:


* Repositories can use pack200 to drastically reduce transfer costs and disk footprint

* Repositories contain p2 metadata that would otherwise need to be generated on the fly by p2 on first startup

* As projects start to produce and exploit more advanced p2 metadata, it can no longer be generated on the fly (think chmod and sym-link metadata for example)

* A project can produce a single repository containing all of their project's output. Consumers then have the flexibility to install only the portions they need. In the past this consumer flexibility was only possible by having the producer provide numerous zip files containing the different permutations of their project output. These large collections of zips are a maintenance nightmare for producers, and lead to slower builds and higher disk usage.


On the other hand, remote repositories don't make for a reliable build input. They expose builds to transient communication failures, they may change or be deleted, they are difficult to mirror, they add to bandwidth costs if they are consumed remotely on every build, etc.


So, how do projects offer all of the advantages of both zips and p2 repositories? The answer: zipped p2 repositories. Simply take the p2 repositories you are producing today, zip them up, and make them available on your project download page. Consumers can then download these repositories, and use them offline in all the same ways they use either zips or remote repositories today. The p2 team is now recommending this zipped repository format as the downloadable format of the future. For more details, see this wiki page:


http://wiki.eclipse.org/Equinox/p2/Metadata_Consumption

Thanks,

The p2 team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev[attachment "pic30390.gif" deleted by Pascal Rapicault/Ottawa/IBM] _______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


GIF image

GIF image

GIF image


Back to the top