Developer's guide to upgrading the AJDT build to a newer version of Eclipse

From Eclipsepedia

Revision as of 00:48, 11 December 2008 by Andrew.eisenberg.as (Talk | contribs)

Jump to: navigation, search

Steps required to change the version of Eclipse used to build and AJDT and run the tests. As an example we will consider an upgrade from Eclipse 3.3M3 to 3.3M4:

Download new Eclipse-SDK (such eclipse-SDK-3.3M4-linux-gtk.tar.gz) and also eclipse-test-framework-3.3M4.zip (listed under JUnit Plugin Tests and Automated Testing Framework)

From the CruiseControl build directory on the build machine, rename old dir "eclipse33" to "eclipse33-old-M3". Create new dir "eclipse33" and unpack new SDK into it - so that you have a path of eclipse33/eclipse/startup.jar.

Go to "test" sub-dir and rename old dir "eclipse33" to "eclipse33-old-M3". Unpack new SDK again - so that this time you have a path of eclipse33/startup.jar. Also unpack the test framework zip file at the same level. Go into eclipse33/plugins and rename org.eclipse.test_?.?.? to just "org.eclipse.test".

The script which runs the tests expects a startup.jar file in the "eclipse33" directory. Newer eclipse builds don't have this, so it needs to be copied from the plugins dir with "cp plugins/org.eclipse.equinox.launcher_.*.jar startup.jar"


That should be it, but there are often some workarounds required for specific issues. Here is the current list:

Delete test/eclipse33/plugins/org.eclipse.jdt.compiler.tool.*.jar as this new plugin requires Java 6, so will cause a warning which will result in a test failure (the tests are run under Java 5)

Edit test/eclipse33/plugins/org.eclipse.test/library.xml and add "-XX:MaxPermSize=128m" to the value of the "extraVMargs" property (see bug 130545)


Contents

Update:

Here is how I upgraded from Eclipse 3.4 RC1 to Eclipse 3.4 final. Slightly different than above:

  1. Download eclipse classic: eclipse-SDK-3.4-linux-gtk.tar.gz
  2. Move eclipse34 directory to eclipse34rc1-old
  3. Unpack downloaded zip into eclipse34/eclipse directory
  4. Move test/eclipse34 directory to test/eclipse34rc1-old
  5. Unpack again into test directory
  6. Copy test/eclipse34rc1-old/*test*.xml and test/eclipse34rc1-old/ui_session_sniff_folder/ into test/eclipse34
  7. Copy the test framework plugins (ie- eclipse34rc1-old/plugins/*test*) into the plugin directory of eclipse34 for both places I unpacked (note that for 3.5 or later versions, you will need to download the eclipse testing framework separately and follow the steps above)
  8. Run ant -f build-ajdt1.6.xml to make sure that the new eclipse version works

Building with a later version of Eclipse

When I started working in this project, all the builds were being performed by a headless Eclipse 3.2. Here is how I upgraded the AJDT 1.6 builds to use Eclipse 3.4 instead.

  1. Updated the org.eclipse.ajdt.pde.build plugin to work with Eclipse 3.4
  2. Patched the pdebuild-ant.jar as explained in Developer's guide to driving the AJDT build process
  3. Made a backup of build-ajdt1.6.xml
  4. Then I made 4 changes to the file
    1. Changed the dir attribute in the java command in the pdebuild target to "eclipse34/eclipse/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts"
    2. Changed the jar attribute to eclipse34/eclipse/plugins/org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar"
    3. In the optimized launcher changed the jar attribute to "eclipse34/eclipse/plugins/org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar" (did this twice)
  5. Copied over the relevant AJDT plugins into the Eclipse 3.4 plugins directory (org.aspectj.weaver, org.aspectj.runtime, org.aspectj.ajde). I just grabbed these plugins from the artifacts directory.
  6. Last one is kind of a bit hacky. I had to edit one of the standard buildscripts that came with Eclipse in the directory /home/build/cruisecontrol-2.3.1/eclipse34/eclipse/plugins/org.eclipse.pde.build_3.4.0.v20080604/scripts there is a genericTargets.xml and a genericTargets.xml.orig. Do a diff of the two files to see what I changed. The reason why I had to change this (I think) is that the AJModelBuildScriptGenerator is not up to date with using the latest pdebuild. This is the ant task that gets called in order to build the plugins. And so I had to modify the script so that the invalid arguments weren't being passed in.

Turns out that this process was not so simple. By upgrading to have the build server use Eclipse 3.4 to drive the headless build (instead of 3.2), some tricky things had to change. Here is a list of them:

  1. The ant task eclipse.idReplacer that is defined by Java class IdReplaceTask takes a different format for one of its input arguments. Had to change that.
  2. Also, the plugins that the build process compiled against can not contain any duplicates of the plugins being compiled. This is a difference from Eclipse 3.2, which was more lax about this. I edited the build-AJDT1.6.xml so that the baseLocation argument to the pdebuild task pointed to the pluginPath directory.


Getting AJDT to build headless from Eclipse (to test the build process locally)

  1. Download from cvs *all* ajdt related projects into your workspace
  2. Edit the launch configuration ant_headless_build
  3. In the arguments tab enter some reasonable values for all arguments.
  4. The help file http://127.0.0.1:56879/help/topic/org.eclipse.pde.doc.user/tasks/pde_feature_generating_antcommandline.htm has information on all arguments.
  5. Of particular note is the pluginPath argument. This is a path to the plugins to compile against. It must contain all required plugins (ie- standard eclipse plus mylyn, but *no* ajdt plugins).
  6. Launch the configuration and cross your fingers...

The nice part about this is that you can run the build process through the debugger and see all the steps as they occur.


Installing Eclipse Testing Framework in a world with P2

I had a heck of a time getting the testing framework to install properly when P2 was involved.

This page has some very good information on how to do it: http://rcpquickstart.com/2007/08/06/running-automated-tests-with-pde-build/

Quote:

Greetings to those struggling to get automated testing to work with 3.4. In the past, our process was as follows:

1) Build our plugin(s). 2) Copy our plugins to an eclipse installation (i.e. eclipse-SDK-3.4.1) that also contains the ETF plugins (i.e. eclipse-test-framework-3.4.1). 3) Launch the ETF with a test.xml file that invokes our JUnit test classes.

When we get to step 3, the launcher fails with Java 13 error.

Eclipse 3.4 contains changes for the new update manager (i.e. P2). This new functionality makes eclipse much more picky about what plugins it will load. You can’t just copy your plugin(s) into the eclipse plugin folder or even the dropin folder and then launch ETF - the framework will not see them and you’ll get the error.

To work around this, do the following:

  1. Setup your test installation of eclipse (unzip eclipse-SDK and eclipse-test-framework to the same location).
  2. Add any plugins that you depend on (but do not build) to this installation.
  3. Startup the test installation. Run “Help->Software Updates->Update…” if you like.
  4. Exit the test eclipse installation.
  5. Build your plugins.
  6. Place them in the dropins directory of your test installation.
  7. Startup the test installation of eclipse. Make sure you can see your plugins when you choose “Help->About Eclipse SDK->Plug-in Details”. You may need to restart a couple of times. If you can’t see your plugins, you have a dependency problem that you need to fix.
  8. Exit the test installation of eclipse. Remove your plugin(s) from the dropin directory. Then MAKE A ZIP OF THE TEST INSTALLATION.

Your automated build process should be changed to resemble the following:

  1. Build your plugin(s).
  2. Blow away the existing test environment and re-create it from the zip you saved in step 8) above.
  3. Copy your plugin(s) to the dropin directory.

4) Launch ETF with your test.xml file. It should load your plugin(s) and run your test.

It’s important to run step 2 every time since even a successful invocation of ETF will hose the test environment so that it won’t work the next time.

End Quote

All right. This page is messy. Needs rewrite.