Jump to: navigation, search

Difference between revisions of "Developer's guide to upgrading the AJDT build to a newer version of Eclipse"

(Major rewrite for upgrading to 1.7)
Line 1: Line 1:
Steps required to change the version of Eclipse used to build and AJDT and run the tests.
+
===Starting a build process of the next version of AJDT on the next version of Eclipse===
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)
+
Here are the steps I took to add AJDT 1.7 to the build process. AJDT 1.7 uses Eclipse 3.5 to build it.
  
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.
+
# upload new version of eclipse to build server (should be something like eclipse-SDK-3.5M5-linux-gtk.tar.gz)
 +
# unzip it into cruisecontrol/eclipse35/eclipse
 +
# unzip again into test/eclipse35
 +
# copy build-ajdt1.6.xml, publish1.6.xml, upload1.6.xml, run-tests34.sh to the new version. Use the same naming convention as before (change 1.6 to 1.7 and 34 to 35).  And edit so that the appropriate version numbers, paths, and plugin ids are used (probably need to look at version numbers in the unzipped eclipse).
 +
# upload a zip of mylyn that works with the target eclipse '''be sure to include mylyn's dependencies (eg- org.apache.commons.lang and org.apache.commons.codec)'''
 +
# unzip mylyn and dependencies into both eclipse installs
 +
# update ajdt.pde.build plugin for latest version of eclipse (this part may be tricky.  see below for more on this).  create the ajdtbuild-ant.jar by using pdebuild.jardesc
 +
# export ajdt.pde.build plugin (make sure that "package plug-ins as individul JAR archives" is '''un'''checked), upload it to build server, and place it into eclipse35/eclipse/plugins
 +
# add AJ runtime, weaver, and ajde jars to eclipse (set it in the eclipse3X directory).  They are required for the iajc task, but they cannot be in the plugins directory.  They go in the devEntries property in build-ajdt1.7.xml.
 +
# upload eclipse testing framework (listed under JUnit Plugin Tests and Automated Testing Framework in the eclipse downloads page).  Place it in the plugins directory for the test eclipse.
 +
# edit test eclipse's config.ini so that it recognizes EA
 +
# make the appropriate directories on download server (mirror the directory structure for earlier versions)
 +
# edit config.xml and add section for new build
 +
# OPTIONAL To see if all the unzipped plugins are working, you can execute the command "eclipse -console" for the osgi console.  Then type "ss" command to get a list of installed bundles. Make sure everything that you expect to be there is.
  
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".
+
===Notes on getting pde jar working===
  
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"
+
* Test it locally first!  See below.
 
+
* Do not export with a qualifier (makes it easier to upgrade)
----
+
* Do not export as 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)
+
 
+
----
+
 
+
===Update:===
+
 
+
Here is how I upgraded from Eclipse 3.4 RC1 to Eclipse 3.4 final.  Slightly different than above:
+
 
+
# Download eclipse classic: eclipse-SDK-3.4-linux-gtk.tar.gz
+
# Move eclipse34 directory to eclipse34rc1-old
+
# Unpack downloaded zip into eclipse34/eclipse directory
+
# Move test/eclipse34 directory to test/eclipse34rc1-old
+
# Unpack again into test directory
+
# Copy test/eclipse34rc1-old/*test*.xml and test/eclipse34rc1-old/ui_session_sniff_folder/ into test/eclipse34
+
# 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)
+
# 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.
+
 
+
# Updated the org.eclipse.ajdt.pde.build plugin to work with Eclipse 3.4
+
# Patched the pdebuild-ant.jar as explained in [[Developer's guide to driving the AJDT build process]]
+
# Made a backup of build-ajdt1.6.xml
+
# Then I made 4 changes to the file
+
## 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"
+
## Changed the jar attribute to eclipse34/eclipse/plugins/org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar"
+
## 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)
+
# 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.
+
# 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:
+
 
+
# 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.
+
# 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.
+
  
  
Line 64: Line 36:
 
The nice part about this is that you can run the build process through the debugger and see all the steps as they occur.
 
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:
 
 
# Setup your test installation of eclipse (unzip eclipse-SDK and eclipse-test-framework to the same location).
 
# Add any plugins that you depend on (but do not build) to this installation.
 
# Startup the test installation. Run “Help->Software Updates->Update…” if you like.
 
# Exit the test eclipse installation.
 
# Build your plugins.
 
# Place them in the dropins directory of your test installation.
 
# 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.
 
# 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:
 
 
# Build your plugin(s).
 
# Blow away the existing test environment and re-create it from the zip you saved in step 8) above.
 
# 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.
 
  
 
[[Category:AJDT]]
 
[[Category:AJDT]]

Revision as of 22:53, 12 March 2009

Starting a build process of the next version of AJDT on the next version of Eclipse

Here are the steps I took to add AJDT 1.7 to the build process. AJDT 1.7 uses Eclipse 3.5 to build it.

  1. upload new version of eclipse to build server (should be something like eclipse-SDK-3.5M5-linux-gtk.tar.gz)
  2. unzip it into cruisecontrol/eclipse35/eclipse
  3. unzip again into test/eclipse35
  4. copy build-ajdt1.6.xml, publish1.6.xml, upload1.6.xml, run-tests34.sh to the new version. Use the same naming convention as before (change 1.6 to 1.7 and 34 to 35). And edit so that the appropriate version numbers, paths, and plugin ids are used (probably need to look at version numbers in the unzipped eclipse).
  5. upload a zip of mylyn that works with the target eclipse be sure to include mylyn's dependencies (eg- org.apache.commons.lang and org.apache.commons.codec)
  6. unzip mylyn and dependencies into both eclipse installs
  7. update ajdt.pde.build plugin for latest version of eclipse (this part may be tricky. see below for more on this). create the ajdtbuild-ant.jar by using pdebuild.jardesc
  8. export ajdt.pde.build plugin (make sure that "package plug-ins as individul JAR archives" is unchecked), upload it to build server, and place it into eclipse35/eclipse/plugins
  9. add AJ runtime, weaver, and ajde jars to eclipse (set it in the eclipse3X directory). They are required for the iajc task, but they cannot be in the plugins directory. They go in the devEntries property in build-ajdt1.7.xml.
  10. upload eclipse testing framework (listed under JUnit Plugin Tests and Automated Testing Framework in the eclipse downloads page). Place it in the plugins directory for the test eclipse.
  11. edit test eclipse's config.ini so that it recognizes EA
  12. make the appropriate directories on download server (mirror the directory structure for earlier versions)
  13. edit config.xml and add section for new build
  14. OPTIONAL To see if all the unzipped plugins are working, you can execute the command "eclipse -console" for the osgi console. Then type "ss" command to get a list of installed bundles. Make sure everything that you expect to be there is.

Notes on getting pde jar working

  • Test it locally first! See below.
  • Do not export with a qualifier (makes it easier to upgrade)
  • Do not export as jar


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.