Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Equinox p2 build and consumption"

(New page: This document review the implication of p2 on what/how people build and how the consumption of the build output is affected. {| class="wikitable" |- ! Plugins / features ready to run (FTR...)
 
Line 1: Line 1:
 
This document review the implication of p2 on what/how people build and how the consumption of the build output is affected.
 
This document review the implication of p2 on what/how people build and how the consumption of the build output is affected.
−
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Plugins / features ready to run (FTR)
+
!Items that are being produced today
−
! header 2
+
!Same items in the context of p2
−
! header 3
+
 
|-
 
|-
−
| row 1, cell 1
+
|Plugins / features ready to run, referred as FTR.  FTRs are used in the following ways:
−
| row 1, cell 2
+
<p>a) Unzipping, and running with -clean</p>
−
| row 1, cell 3
+
 
−
|-
+
<p>b) Creating ‘products’:</p>
−
| row 2, cell 1
+
−
| row 2, cell 2
+
<p>b.1) by extracting in a links folder</p>
−
| row 2, cell 3
+
 
−
|}
+
<p>b.2) by unzipping on top of an eclipse install and rezipping</p>
 +
 +
<p>b.3) by using pde packager</p>
 +
  <p>c.1) by unzipping and rezipping</p>
 +
  <p>c.2) by using packager</p>
 +
  <p>d) Replacing thing in an existing base</p>
 +
  <p>&nbsp;</p>
 +
 
 +
  |
 +
  <p>With p2, FTR should preferably contain a content.xml. The
 +
  motivation is to have consistency among the IUs that are being used when
 +
  installing from a repo or not. This also avoids problems if the metadata
 +
  generator evolves and produces different IUs since what could have been
 +
  published.</p>
 +
  <p>&nbsp;</p>
 +
  <p>a) This is supported by the drop-ins folder support. We
 +
  need to ensure that it works appropriately when there is a content.xml. There
 +
  are some restrictions since the content.xml could apply, therefore it is
 +
  recommended for people to use a links folder structure rather than wild
 +
  unzipping.</p>
 +
  <p>b) Because
 +
  of the p2 folder and the bundles.txt at the root of the product, and the content.xm,
 +
  some of these scenarios  become non-trivial, since the bundles.txt has to be
 +
  created, the content.xmls could collide if multiple things were being
 +
  unzipped. But let’s review the details</p>
 +
  <p> b.1) This scenario does not
 +
  change. The initial startup of the application will discover the content of
 +
  the links folder and all p2 data structures (bundles.txt, p2 folder) will be
 +
  updated appropriately.</p>
 +
  <p> b.2) Because of the p2 metadata
 +
  and the bundles.txt at the root of the product, and the content.xml, this
 +
  scenario becomes non-trivial (there may be some answers from the shared
 +
  install scenario).</p>
 +
  <p>The current recommendation here
 +
  is to use links folders (b.1). It is a change, but it actually represents an
 +
  improvement since things can just be dropped.</p>
 +
  <p>b.3) In this case the packager becomes a
 +
  provisioning operation and nothing special has to happen. What happens when
 +
  no content.xml exist?</p>
 +
  <p>c.1) The only difficulty here is on merging the
 +
  content.xml. However this should be doable by running the repository
 +
  mirroring tool. What happens when no content.xml exist?</p>
 +
  <p>c.2) In this case the packager also relies on the
 +
  repository mirroring tool. What happens when no content.xml exist?</p>
 +
  <p>d) This will be supported with the generation of patch
 +
  metadata.</p>
 +
 
 +
 +
|-
 +
|
 +
 
 +
  <p>Update sites</p>
 +
  <p>d) the update site is directly published for users to
 +
  connect to.</p>
 +
  <p>e) the update site is zipped and published for the user to
 +
  download and use as a local site</p>
 +
 
 +
|
 +
  <p>Both scenarios are supported by producing appropriate p2
 +
  metadata as part of the build.</p>
 +
 
 +
 +
|-
 +
|
 +
  <p>Eclipse-based products and how they are built</p>
 +
  <p>f) product build in PDE</p>
 +
  <p>g) adding a few things on top of eclipse (e.g.
 +
  WTP all in one, EPP packages)</p>
 +
  <p>h) homebrewed</p>
 +
  <p>i) eclipse base + links folder containing
 +
  plug-ins in a runnable form</p>
 +
 
 +
  |
 +
  <p>Products need to have a corresponding IU (it aggregates
 +
  the features, the plugins and the various configuration bits).</p>
 +
  <p>f) product build needs to be made p2 aware to produce the
 +
  product IU and also create the product by invoking a p2 operation.</p>
 +
  <p>g) same difficulty than b.2. The recommended way is to use
 +
  a provisioning operation </p>
 +
  <p>h) the way to go is to provide the various archives of the
 +
  product, a .product file and invoke a p2-izer operation. May not be supported
 +
  immediately.</p>
 +
  <p>i) See b.1.</p>

Revision as of 13:05, 21 February 2008

This document review the implication of p2 on what/how people build and how the consumption of the build output is affected.

Items that are being produced today Same items in the context of p2
Plugins / features ready to run, referred as FTR. FTRs are used in the following ways:

a) Unzipping, and running with -clean

b) Creating ‘products’:

b.1) by extracting in a links folder

b.2) by unzipping on top of an eclipse install and rezipping

b.3) by using pde packager

c.1) by unzipping and rezipping

c.2) by using packager

d) Replacing thing in an existing base

 

With p2, FTR should preferably contain a content.xml. The motivation is to have consistency among the IUs that are being used when installing from a repo or not. This also avoids problems if the metadata generator evolves and produces different IUs since what could have been published.

 

a) This is supported by the drop-ins folder support. We need to ensure that it works appropriately when there is a content.xml. There are some restrictions since the content.xml could apply, therefore it is recommended for people to use a links folder structure rather than wild unzipping.

b) Because of the p2 folder and the bundles.txt at the root of the product, and the content.xm, some of these scenarios become non-trivial, since the bundles.txt has to be created, the content.xmls could collide if multiple things were being unzipped. But let’s review the details

b.1) This scenario does not change. The initial startup of the application will discover the content of the links folder and all p2 data structures (bundles.txt, p2 folder) will be updated appropriately.

b.2) Because of the p2 metadata and the bundles.txt at the root of the product, and the content.xml, this scenario becomes non-trivial (there may be some answers from the shared install scenario).

The current recommendation here is to use links folders (b.1). It is a change, but it actually represents an improvement since things can just be dropped.

b.3) In this case the packager becomes a provisioning operation and nothing special has to happen. What happens when no content.xml exist?

c.1) The only difficulty here is on merging the content.xml. However this should be doable by running the repository mirroring tool. What happens when no content.xml exist?

c.2) In this case the packager also relies on the repository mirroring tool. What happens when no content.xml exist?

d) This will be supported with the generation of patch metadata.


Update sites

d) the update site is directly published for users to connect to.

e) the update site is zipped and published for the user to download and use as a local site

Both scenarios are supported by producing appropriate p2 metadata as part of the build.


Eclipse-based products and how they are built

f) product build in PDE

g) adding a few things on top of eclipse (e.g. WTP all in one, EPP packages)

h) homebrewed

i) eclipse base + links folder containing plug-ins in a runnable form

Products need to have a corresponding IU (it aggregates the features, the plugins and the various configuration bits).

f) product build needs to be made p2 aware to produce the product IU and also create the product by invoking a p2 operation.

g) same difficulty than b.2. The recommended way is to use a provisioning operation

h) the way to go is to provide the various archives of the product, a .product file and invoke a p2-izer operation. May not be supported immediately.

i) See b.1.
Retrieved from "https://wiki.eclipse.org/index.php?title=Equinox_p2_build_and_consumption&oldid=83636"

Back to the top