Skip to main content
Jump to: navigation, search

Difference between revisions of "OTBuilding"

(New page: The Object Teams Development Tooling is built in two main stages: == Building and Testing with PDE/Build == == Publishing a p2 Repository == A shell script [http://dev.eclipse.org/viewcv...)
 
Line 18: Line 18:
 
# Generate p2 metadata
 
# Generate p2 metadata
 
# Patch <code>content.xml</code> as to widen the version range of references to <code>org.eclipse.jdt.core.feature.group</code>:
 
# Patch <code>content.xml</code> as to widen the version range of references to <code>org.eclipse.jdt.core.feature.group</code>:
#: ''The patch feature <code>org.eclipse.objectteams.otdt.core.patch</code> must refer to an exact version of the feature which it patches, but even the same jdt bits will create different qualifiers in subsequent builds, so when we build against jdt RC3 it wouldn't be compatible with the final release even if jdt has no changes.''
+
#: ''The patch feature <code>org.eclipse.objectteams.otdt.core.patch</code> must refer to an exact version of the feature which it patches, but even the same jdt bits will create different qualifiers in subsequent builds, so when we build against jdt RC3 it wouldn't be compatible with the final release even if jdt has no changes.'' - see {{bug|304156}}
 +
#: This is done using [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/build/patch-content-xml.xsl?root=TOOLS_OBJECTTEAMS&sortby=file&view=log patch-content-xml.xsl]
 
# Archive category-less metadata as the basis for future builds
 
# Archive category-less metadata as the basis for future builds
#: ''cumulative repositories and categories don't play well together, because a category, once created cannot be augmented''
+
#: ''cumulative repositories and categories don't play well together, because a category, once created cannot be augmented'' see {{bug|251888#c11}}
 
# Generate the category
 
# Generate the category
 
# Add download statistics capability
 
# Add download statistics capability

Revision as of 14:25, 21 August 2010

The Object Teams Development Tooling is built in two main stages:

Building and Testing with PDE/Build

Publishing a p2 Repository

A shell script createRepository.sh performs these steps:

  1. Jar signing
    • zip all jars into a big ball - skip symlinks which only point to artifacts from previous build
    • send to the signing daemon, wait for the result to appear
  2. Populate a new repository stagingRepo
    • symlink artifacts from existing update site -- this ensures exact same bits, so unchanged plugins can be re-used during updating
      would we copy these files they were more difficult to distinguish/skip in subsequent phases
    • physically copy bcel jar
      how can we ensure that clients in all update-scenarii will find bcel from original orbit repo?
  3. Pack200 all jar files
    apparently conditioning is already performed by PDE/Build for p2?
  4. Generate p2 metadata
  5. Patch content.xml as to widen the version range of references to org.eclipse.jdt.core.feature.group:
    The patch feature org.eclipse.objectteams.otdt.core.patch must refer to an exact version of the feature which it patches, but even the same jdt bits will create different qualifiers in subsequent builds, so when we build against jdt RC3 it wouldn't be compatible with the final release even if jdt has no changes. - see bug 304156
    This is done using patch-content-xml.xsl
  6. Archive category-less metadata as the basis for future builds
    cumulative repositories and categories don't play well together, because a category, once created cannot be augmented see bug 251888#c11
  7. Generate the category
  8. Add download statistics capability
    use XSL transformation addDownloadStats.xsl, which may not be a very safe way of doing this
  9. Jar-up metadata
  10. Remove symlinks which were needed to resolve dependencies on previous builds

Now the stagingRepo is ready to be copied over the previously published repository.

The script accepts these parameters:

createRepository.sh updateMasterRelativePath [ -nosign ] [ statsRepoId statsVersionId ]
  • updateMasterRelativePath:
relative path under downloads/objectteams/updates pointing to a repository from which to resolve unchanged bundles/features
specify none for an un-parented repository
  • -nosign
skip signing
  • statsRepoId
this identifies the repository in the download statistics, currently either 0.7 or unstable
  • statsVersionId
this identifies the version in the downloading statistics, currently 0.7.1

Back to the top