Skip to main content

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

> it would help if the Wiki page that you reference contained answers
> to the following questions:

> How do I use a zipped repository for unattended (scripted) installs?
> Can my scripted install directly install from the zipped repository? Why not?
A zipped repo is just a repo, so you should be able to use it in a scripted install. I will update the wiki page with the appropriate information.

> How do I perform scripted install for platforms other than the one I'm running on (e.g. in order to assemble a product)?
Simply feed the repo to PDE Build. Eclipse M5 New and Noteworthy

> What are known issues and workarounds?
We have no known issues yet directly related to the creation of those repos. We created the wiki page to actually capture those as they come up.

> See bug 264427 for instance
This issue happens independently of whether or not we are doing this. This use case has not been considered by the UI Workgroup.

> Below is a commandline which I'm currently using for scripted
> install of CDT. I find it quite complex, is there any chance to
> simplify usage of p2 director?

> [...cmd line...]
It all depends what the intent is here. If you are really willing to install CDT into eclipse to create a product you deliver, then creating repos does not help in simplifying this. If you are using the resulting install as a target, then the new PDE Build functionality will help.


> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-
> project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
> Sent: Dienstag, 10. Februar 2009 15:49
> To: cross-project-issues-dev@xxxxxxxxxxx
> 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:
> Thanks,
> The p2 team_______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx

Back to the top