Skip to main content
Jump to: navigation, search

Orbit/New Iplog Design

< Orbit
Revision as of 16:34, 19 September 2016 by Rgrunber.redhat.com (Talk | contribs) (p2 Repository IPlog Data Format)

New IPlog HTML Generation

Warning2.png
Draft / Proposal
This is a draft plan being proposed. Please submit comments/feedback to orbit-dev@eclipse.org.


p2 Repository IPlog Data Format

The old (R-build) and new (orbit-recipes) p2 repositories will need to be modified just after being built so that they contain the IPlog metadata necessary to generate the final IPlog HTML page.

The IPLog metadata for a bundle looks as follow :

<ip_log version="1.0">
 <project id="org.apache.lucene.core" version="5.2.1" status="done">
   <info>
     <name>Lucene Core</name>
     <repository>scm:git:git.eclipse.org:/gitroot/orbit/recipes.git</repository>
     <location>lucene/org.apache.lucene.core</location>
   </info>
   <contact>
     <name>Roland Grunberg</name>
     <email>rgrunber@redhat.com</email>
     <company>Red Hat</company>
   </contact>
   <legal>
     <ipzilla bug_id="10145"/>
     <license>
       <name>Apache License, 2.0</name>
       <reference>http://www.apache.org/licenses/LICENSE-2.0.txt</reference>
     </license>
     <package>lucene-core-5.2.1.jar</package>
   </legal>
 </project>
</ip_log>

Since this is data describing content rather than the location of that content, it makes sense to place the IPlog metadata within the p2 Metadata Repository (eg. content.xml/content.jar) and not the Artifact Repository (artifacts.xml/artifacts.jar).

The simplest way to achieve this is by placing all '<project>' elements within an '<iplog>' element, within the '<repository>' element and just after the 'units' element :

<repository name='Orbit Repository (Build I-I201609142113-201609142113)'
  type='org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository' version='1'>
<properties size='2'>
  <property name='p2.timestamp' value='1460576500885'/>
  <property name='p2.compressed' value='true'/>
</properties>
<units size='82'>
 <unit id='org.apache.lucene.core' version='5.2.1.v20160301-1110' singleton='false'>
     <update id='org.apache.lucene.core' range='[0.0.0,5.2.1.v20160301-1110)' severity='0'/>
     <properties size='7'>
       <property name='df_LT.bundleVendor' value='Eclipse Orbit'/>
       ...
       ...
       <property name='maven-version' value='5.2.1-SNAPSHOT'/>
       <property name='iplog.contact.name' value='Roland Grunberg'>
       <property name='iplog.contact.email' value='rgrunber@redhat.com'>
       <property name='iplog.bug_id' value='10145'>
     </properties>
     <provides size='24'>
       <provided namespace='org.eclipse.equinox.p2.iu' name='org.apache.lucene.core' version='5.2.1.v20160301-1110'/>
       ...
       ...
       <provided namespace='java.package' name='org.apache.lucene.util' version='5.2.1'/>
     </provides>
     <artifacts size='1'>
       <artifact classifier='osgi.bundle' id='org.apache.lucene.core' version='5.2.1.v20160301-1110'/>
     </artifacts>
     <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/>
     <touchpointData size='1'>
       <instructions size='1'>
         <instruction key='manifest'>
           Bundle-SymbolicName: org.apache.lucene.core
Bundle-Version: 5.2.1.v20160301-1110
         </instruction>
       </instructions>
     </touchpointData>
   </unit>
 </units>
 </repository>


This approach avoids having any of that metadata being used at installation time, and should avoid disturbing normal p2 operations on a repository.

These p2 repositories are ultimately children of a composite repository :

<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='Eclipse Orbit Composite Site N20160914211330'
   type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' version='1.0.0'>
 <properties size='1'>
   <property name='p2.timestamp' value='20160914211330'/>
 </properties>
 <children size='2'>
   <child location='../../../downloads/drops/R20160520211859/repository'/>
   <child location='../../../downloads/drops2/N20160914211328/repository'/>
 </children>
</repository>

Conversion From Composite Repository To IPlog Page

Once we've generate the final composite repository, which points to the old content (R-build) and new (orbit-recipes) content, we can pass it to our php script to extract the IPlog metadata from within those children repositories. This could happen near the very end of the build process (after composite creation).

cat compositeContent.xml | curl -o index.html -d @- http://download.eclipse.org/tools/orbit/downloads/iplog.php?repoPath='http://download.eclipse.org/tools/orbit/downloads/drops/N20160914211330'
  1. The composite metadata repository is passed to the php script along with 'repoPath' (the path to use when resolving relative children paths within the composite)
  2. The composite metadata repository is parsed to determine the relative location of the children repositories
  3. The children repository relative locations are appended to 'repoPath'
  4. The new children locations are parsed as XML and transformed using an XSLT that targets the IPlog metadata and embeds it into the final HTML page
  5. The generated index.html page can now be placed within the generated repository on disk

Back to the top