TaxonomicEditorP2UpdateSite¶

NOTE: With TaxonomicEditorUpdateSiteManualDeployment a predecessor to this page exists which is outdated but kept for reference to depict the former process of deploying plugin updated to the p2 site.

• Table of contents
• TaxonomicEditorP2UpdateSite
  • Deployment of releases to the p2 site
  • Automatic updating of the Taxonomic Editor
    • Involved classes
    • Useful resources
    • Debugging the update process
      • Logging
      • Debugger
    • Local caches
    • Checking for new updates as seen at the server side
    • Network throughput dependency
    • Related tickets

Deployment of releases to the p2 site¶

TODO (see pom.xml and http://int.e-taxonomy.eu/jenkins/view/EDIT%20Taxonomic%20Editor/job/taxeditor-PROVISION/)

Automatic updating of the Taxonomic Editor¶

This section describes the technical details of updating the Taxonomic Editor via the p2 site.

Involved classes¶

• eu.etaxonomy.taxeditor.handler.update.P2Util
• (org.eclipse.equinox.internal.p2.updatechecker.UpdateChecker This class would be used when doing UI controlled updates like when using the Help > Check for updates... function in eclipse)
• org.eclipse.equinox.p2.operations.UpdateOperation <--- THIS IS THE CLASS TRIGGERING THE UPDATE CHECKS!!!
  • --> UpdateOperation.updatesFor(IInstallableUnit iu, IProfile profile, IProgressMonitor monitor) computes the actual update information or uses the cache:

private HashMap<IInstallableUnit, List<Update>> possibleUpdatesByIU = new HashMap<IInstallableUnit, List<Update>>();

private Update[] updatesFor(IInstallableUnit iu, IProfile profile, IProgressMonitor monitor) {

  if (possibleUpdatesByIU.containsKey(iu)) {
      // We've already looked them up in the planner, use the cache
      updates = possibleUpdatesByIU.get(iu);
  } else {
      // We must consult the planner
      IQueryResult<IInstallableUnit> replacements = session.getPlanner().updatesFor(iu, context, monitor);
      ... 
      possibleUpdatesByIU.put(iu, updates);
  }
}

• --> computeProfileChangeRequest(MultiStatus status, IProgressMonitor monitor)

IQueryResult<IInstallableUnit> replacements = session.getPlanner().updatesFor(iu, context, monitor);

• --> org.eclipse.equinox.internal.p2.director.SimplePlanner.updatesFor()

Useful resources¶

• http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application
• http://bugs.eclipse.org/281226
• http://www.vogella.com/tutorials/EclipseP2Update/article.html

Debugging the update process¶

Logging¶

Since we are using the org.eclipse.equinox.p2.operations.UpdateOperation for auomatic in app updates the below mentioned debugging technique does not work at all. UpdateOperation and other involved classes to not produce any tracing information.

Some hints on debuggin update processes are given in https://wiki.eclipse.org/Equinox/p2/Getting_Started#Debugging_dropins but these instructions don't seem to work with the Taxonomic Editor.

General information on tracing in eclipse application can be found in https://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility.

Debugger¶

For debugging the automatic update maintained by UpdateOperation (see section on classes above) you may want to install org.eclipse.equinox.internal.p2.director as additional plugin in eu.etaxonomy.taxeditor.store/META-INF/MANIFEST.MF:

Local caches¶

the p2 caches are located in the application folder:

./p2/org.eclipse.equinox.p2.repository/
./p2/org.eclipse.equinox.p2.core/cache/
./p2/org.eclipse.equinox.p2.engine/ // DO NOT DELETE !!!!

./p2/org.eclipse.equinox.p2.engine/profileRegistry/DefaultProfile.profile/ MUST NOT be deleted, otherwise the updater will not be able to check for updates and the UI will erroneously always present the dialog asking the user to install the updates.

Checking for available updates will modify the contents of the ./p2/ folder by adding files (new files in bold letters)

• ./p2/org.eclipse.equinox.p2.engine(profileRegistry/DefaultProfile.profile/.data/.settings/*.prefs
• ./p2/org.eclipse.equinox.p2.engine/profileRegistry/DefaultProfile.profile/159*.profile.gz - the modifiaction time of new files is newer the parent folder
• ./p2/org.eclipse.equinox.p2.repository/ - this folder does not exist initially

Checking for new updates as seen at the server side¶

(see also #7079)

User-agent strings:

HEAD requests:

• Apache-HttpClient/4.3.6 (java 1.5)

GET requests:

• p2/1.1.201.v20161115-1927 (Java 1.8.0_121-b13 Oracle Corporation; Windows7 6.1.0 x86-64; de_DE) eu.etaxonomy.taxeditor.application.eu_etaxonomy_taxeditor_product/unknownBuildId (eu.etaxonomy.taxeditor.application.application)
• p2/1.1.201.v20161115-1927 (Java 1.8.0_131-b11 Oracle Corporation; Linux 5.3.0 x86-64; en_US) eu.etaxonomy.taxeditor.application.eu_etaxonomy_taxeditor_product/unknownBuildId (eu.etaxonomy.taxeditor.application.application)

First check which finds a new content.xml.xz:

cybertaxonomy.eu:443 "GET /download/taxeditor/update/stable/p2.index HTTP/1.1" 200 7442
cybertaxonomy.eu:443 "HEAD /download/taxeditor/update/stable/content.xml.xz HTTP/1.1" 200 6888 
cybertaxonomy.eu:443 "GET /download/taxeditor/update/stable/content.xml.xz HTTP/1.1" 200 49621

unless the updated timestamp of content.xml.xz changes, the client side p2 component stops after the HEAD request:

cybertaxonomy.eu:443 "GET /download/taxeditor/update/stable/p2.index HTTP/1.1" 200 7442 
cybertaxonomy.eu:443 "HEAD /download/taxeditor/update/stable/content.xml.xz HTTP/1.1" 200 6888

Network throughput dependency¶

The automatic update has been tested with the network-condition-simulator.sh at the following values [DELAY="500ms" DELAY_JITTER="20ms" RATE="56kbit" // :modem speed] and no problems could be observed.

Related tickets¶

issued tagged with eclipse-p2

• #7079