[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] Producing downloadable p2 repositories
|
Hi John,
it would help if the Wiki page that you reference
contained answers to the following questions:
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?
./eclipse/eclipse
-nosplash \
-data install-ws -consolelog -clean \
-application org.eclipse.equinox.p2.director.app.application \
-metadataRepository file:${curdir}/install-ws/ \
-artifactRepository
file:${curdir}/install-ws/ \
-installIU org.eclipse.cdt.feature.group
\
-vmargs \
-Xms128M -Xmx256M -XX:PermSize=128M
-XX:MaxPermSize=256M
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
