Skip to main content
Jump to: navigation, search

Difference between revisions of "Index.php?title=OTBuilding"

(New page: The Object Teams Development Tooling is built in two main stages: == Building and Testing with PDE/Build == This is basically a plain vanilla PDE/Build setup with the following customiza...)
 
(this page was accidentally created, link to real page instead)
 
Line 1: Line 1:
The Object Teams Development Tooling is built in two main stages:
+
#REDIRECT [[OTBuilding]]
 
+
== Building and Testing with PDE/Build ==
+
 
+
This is basically a plain vanilla PDE/Build setup with the following customizations:
+
 
+
* a top-level [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/build/run.xml?root=TOOLS_OBJECTTEAMS&sortby=file&view=log build.xml] ant file initializes a myriad of properties and then
+
*# prepare building:
+
*#* unzip a drop of the Eclipse SDK
+
*#* put <code>org.eclipse.team.svn.pde.build</code> into dropins (''patched version to handle <code>trunk</code> as expected, {{bug|301045}}'')
+
*# create the OT/J compiler by 1. invocation of PDE/Build
+
*# build the OTDT and tests by 2. invocation of PDE/Build
+
*#* preparations ''before'' this stage
+
*#** unpack <code>eclipse-test-framework</code> to make it available while compiling tests
+
*#** pre-load the output repository location from the previous build including category-less metadata
+
*#* polish ''after'' this stage
+
*#** patch <code>content.xml</code> re version range in feature reference from patch feature (see also below, Publishing step 5)
+
*# delegate to the next level for testing
+
* the main [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/build/build.xml?root=TOOLS_OBJECTTEAMS&sortby=file&view=log build.xml] is a fairly thin layer for steps 2 & 3 above: it handles some properties and then delegates to one of two final PDE/Build stages:
+
** OT-Compiler: a PDE/Build with a generated <code>build.xml</code> and these customizations:
+
*** fetch [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/map/ot-compiler.map?root=TOOLS_OBJECTTEAMS&sortby=file&view=log ot-compiler.map] from svn
+
*** install the special <code>Bootstrap_MANIFEST.MF</code> in order to create <code>org.eclipse.jdt.core</code> in the exact same version number as we have it in our base install.
+
*** at end of build insert the resulting <code>org.eclipse.jdt.core</code> into the base install (simply replacing the existing plugin jar)
+
** OTDT:  a second PDE/Build with a generated <code>build.xml</code> and these customizations:
+
*** at this stage, the jdt.core is our version, so we can actually compiler OT/J code
+
*** fetch [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/map/otdt.map?root=TOOLS_OBJECTTEAMS&sortby=file&view=log otdt.map] from svn
+
*** by setting <code>p2.gathering=true</code> in build.properties we trigger a p2-based build.
+
* the final [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/build/test.xml?root=TOOLS_OBJECTTEAMS&sortby=file&view=log test.xml] drives setup and execution of tests:
+
** create the software-under-test:
+
*** unzip the base Eclipse SDK
+
*** call p2 to install the OTDT from <code>testrun/otdtUpdatesDir</code>
+
** call p2 to install the tests from <code>testrun/updateSiteTests/eclipse</code>
+
** invoke all tests in sequence, has support for parallization (currently unused)
+
 
+
 
+
 
+
== Publishing a p2 Repository ==
+
After building and testing were successful a shell script [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/bin/createRepository.sh?root=TOOLS_OBJECTTEAMS&sortby=file&view=log createRepository.sh] performs these steps:
+
 
+
# 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
+
# Populate a new repository <code>stagingRepo</code>
+
#* 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?''
+
# Pack200 all jar files
+
#: ''apparently conditioning is already performed by PDE/Build for p2?''
+
# 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>:
+
#: ''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
+
#: ''cumulative repositories and categories don't play well together, because a category, once created cannot be augmented'' see {{bug|251888#c11}}
+
# Generate the category
+
# Add download statistics capability
+
#: ''use XSL transformation [http://dev.eclipse.org/viewcvs/index.cgi/trunk/releng/build-scripts/bin/addDownloadStats.xsl?root=TOOLS_OBJECTTEAMS&sortby=file&view=log addDownloadStats.xsl], which may not be a very safe way of doing this''
+
# Jar-up metadata
+
# 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 <code>downloads/objectteams/updates</code> pointing to a repository from which to resolve unchanged bundles/features
+
:: specify <code>none</code> for an un-parented repository
+
* -nosign
+
:: skip signing
+
* statsRepoId
+
:: this identifies the repository in the download statistics, currently either <code>0.7</code> or <code>unstable</code>
+
* statsVersionId
+
:: this identifies the version in the downloading statistics, currently <code>0.7.1</code>
+
 
+
 
+
==Updating to a new Eclipse version==
+
Throughout the build process various version dependencies must be observed, thus moving to a new version of Eclipse to build against involves a number of adjustments:
+
* First our '''SVN branch/tag''' needs to be selected
+
** enter this path in <code>run.properties</code> (for bootstrapping our map files via variable <code>mapVersionTag</code>)
+
** if not building from trunk adjust map files, insert the branch using the <code>tag</code>  property ''(this requires a further patched version of org.eclipse.svn.pde.build to avoid qualifier replacement using the branch name).''
+
* Next the exact '''version of a downloadable SDK''' build must be selected
+
** this version goes into file <code>otdt_prerequisites.sh</code>, variables <code>EVERSION</code> and <code>DROP</code>
+
* on <code>build.eclipse.org</code> I have a script <code>bin/extractVersions</code> that '''extracts these numbers from the SDK tar ball''':
+
** versions of pde.build and equinox.launcher: insert in <code>run.properties</code>
+
** version of the jdt feature:
+
*** short format into <code>run.properties</code> (incl. <code>.next</code>: incremented by one for version range)
+
*** long format into <code>feature.xml</code> of otdt.core.patch
+
** versions of the jdt.core plugin
+
*** original version into <code>{EOT}.otdt.feature/ot-compiler-feature/feature.xml</code> and <code>org.eclipse.jdt.core/META-INF/Boostrap_MANIFEST.MF</code>
+
*** actual OT version in odtd.core.patch
+
 
+
 
+
[[Category:Object Teams]]
+

Latest revision as of 06:59, 5 May 2011

Redirect to:

Back to the top