Skip to main content
Jump to: navigation, search

Platform-releng-faq-obsolete

Revision as of 14:04, 21 October 2005 by Kmoir (Talk | contribs) (platform releng faq)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Eclipse Platform Release Engineering FAQ


What hardware comprises the platform-releng build infrastructure?

The eclipse platform build infrastructure consists of

  1. 2 linux build machines (2GHz, 1GB and PowerMac G5, 2GB )
  2. 2 junit test machines, one windows (2GHz, 1 GB) one linux (2.66 GHz, 1.2 GB )
  3. 4 performance test machines - one set of slower machines (one windows, one linux 2GHz, 512 MB) and one set of fast machines (one windows, one linux 3GHz, 2GB)
  4. 1 linux cvs test server(500MHz, 500MB)
  5. 1 database server with apache derby installed to store performance test results (2.5GHz, 500MB)


Is the Eclipse platform build process completely automated?

Yes, the Eclipse build process starts with a cron job on our main build machine that initiatesa shell script that checks out the builder projects.

  • org.eclipse.releng.eclipsebuilder -> scripts to build each type of drop
  • org.eclipse.releng.basebuilder -> a subset of eclipse plugins required to run the build.
  • we also use several small cvs projects on an internal server that store login credentials, publishing information and jdks

  • Fetch, build and assemble scripts are generated automatically the org.eclipse.pde.build plugin in org.eclipse.releng.basebuilder. Fetch scripts specify the version of code to retreive from the repository. Build scripts are also generated automatically to compile all java code, determine compile order and manage dependancies. Assembly scripts are generated to assemble the compiled code into it's final form, tar.gz, zip etc. We also use custom build scripts that you can see in org.eclipse.releng.eclipsebuilder.

    After the build drops are built, the automated junit and performance testing begins. Tests occur over ssh for Linux machines, and rsh for Windows machines. Each component team contributes it's own tests. Once the tests are completed,the results are copied back to the build machine. Also, the images for the performance tests are generated.


    What's the difference between an integration and nightly build?

    With integration builds, we specify a version of the plugin to retrieve in the map files. (org.eclipse.releng/maps). With nightly builds, we retrieve the plugins specified in the map files from the HEAD stream. The types of builds we run are described here http://download.eclipse.org/eclipse/downloads/build_types.html.


    I would like to recompile eclipse on a platform that is not currently supported. What is the best approach to this? How can I ensure that the community can use my work?

    The best approach is use the source build drop and modify the scripts to support that you are interested in. Then open a bug https://bugs.eclipse.org with product platform and component releng attaching the patches to the scripts that were required to build the new drop.


    How long does the build take to complete?

    It takes three hours for all the drops to be produced. Junit (five hours) and performance tests (eight hours) run in parallel after the drops have been built. It takes a further two hours for the performance results to be generated. We will reduce the amount of time that the build takes in the 3.2 timeframe by implementing faster hardware and more parallel ant tasks.


    When is the next build?

    Please refer to the build schedule http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html


    I'm looking for an older build but can't find them on the download page?

    Check out archive site the http://archive.eclipse.org/eclipse/downloads for vintage builds.


    How do I run the performance tests from the zips provided on the download page?

    Check out this https://bugs.eclipse.org/bugs/show_bug.cgi?id=91229#c3 bug


    What do I need to do to use org.eclipse.releng.basebuilder from HEAD now that the Xerces plugin has been removed?

    If you use the org.eclipse.releng.basebuilder from HEAD in your builds and you use TestVersionTracker to create a test.properties file (search for "TestVersionTracker" in your customTargets.xml build scripts), please read on.

    Some older versions of the TestVersionTracker class required xerces on the classpath. We have removed the xerces jars from the HEAD stream only of org.eclipse.releng.basebuilder.

    For any team broken by this, a <generateTestProperties> custom Ant task has been created which does the same. It is available in the org.eclipse.releng.basebuilder/plugins/org.eclipse.build.tools plug-in from HEAD. To use all you will need to do is the following replacement:

    Replace text such as this (taken from GEF):


    <property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/><br><javac verbose="true" failonerror="true" srcdir="${builderDirectory}/tools" destdir="${builderDirectory}/tools" 
      classpath="${eclipse.home}/plugins/org.apache.xerces_4.0.13/xercesImpl.jar:${eclipse.home}/plugins/org.apache.xerces_4.0.13/xmlParserAPIs.jar"/><br><java classname="TestVersionTracker" >
    
    <arg line="${workingDirectory}/eclipse/features/org.eclipse.gef.test_3.1.0/feature.xml
    ${buildDirectory} ${workingDirectory}/gef-testing/test.properties" /> 
    <classpath>
    <pathelement path="${eclipse.home}/plugins/org.apache.xerces_4.0.13/xercesImpl.jar:${eclipse.home}/plugins/org.apache.xerces_4.0.13/xmlParserAPIs.jar:${builderDirectory}/tools" />
    </classpath><br></java>

    with this:

    <generateTestProperties
    buildDirectory="${buildDirectory}"
    
    featureId="org.eclipse.sdk.tests"
    outputFile="${workingDirectory}/eclipse-testing/test.properties"
    />


    How do I update from 3.1 to 3.1.1 using update manager?

    Refer to this document http://www.eclipse.org/eclipse/platform-releng/updatesfor3.1.1.html


    Best releng practices from our Eclipsecon 2005 poster

    1. Automate the build process from end-to-end and automate early.
    2. Use PDE Build in Eclipse to generate build scripts.
    3. Automate JUnit testing and performance monitoring.
    4. Automate build notifications (email)
    5. Use gentle humiliation to encourage developers to contribute carefully. (Clown nose technique).
    6. Ensure stability in the build process by thorough testing of builder changes.
    7. Schedule builds at regular intervals and enforce rebuild policies.
    8. Use map files in a central cvs repository.
    9. Build on Linux.
    10. Have fun!



    Useful reference documents

    Running a build using the scripts in eclipsebuilder http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.releng.eclipsebuilder/readme.html?rev=HEAD&content-type=text/html

    Automating Builds using PDE Build http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.releng.basebuilder/readme.html?rev=HEAD&content-type=text/html

    Build and Test Automation for plug-ins and features http://eclipse.org/articles/Article-PDE-Automation/automation.html

    Contributing JUnit Plug-in Tests http://www.eclipse.org/eclipse/platform-releng/junit-contributing.html

    Performance Tests how-to http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html

    Eclipse's culture of shipping http://www.artima.com/lejava/articles/eclipse_culture.html

    The Eclipse Way: Proccesses that Adapt http://eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf


    Who are the platform-releng committers?

    The platform releng team consists of Sonia Dimitrov and Kim Moir.

    Back to the top