From a9613a8b37da94a2ad0db8c500970ed09c46480b Mon Sep 17 00:00:00 2001 From: Aidan Skinner Date: Mon, 2 Jun 2008 18:07:05 +0000 Subject: Remove old doc git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/branches/forrest-site@662503 13f79535-47bb-0310-9956-ffa450edef68 --- content/xdocs/SourceHandling.xml | 852 --------------------------------------- 1 file changed, 852 deletions(-) delete mode 100755 content/xdocs/SourceHandling.xml diff --git a/content/xdocs/SourceHandling.xml b/content/xdocs/SourceHandling.xml deleted file mode 100755 index 75a445bd1a..0000000000 --- a/content/xdocs/SourceHandling.xml +++ /dev/null @@ -1,852 +0,0 @@ - - -
- Source Handling Process -
- Source handling - - The JPMC Qpid project involves a lot of code spread across a number of repositories. To safely manage the - code that we build internally we must take several steps to guarrantee its quality. This document details - the processes and procedures we have put in place to guarrantee the code is accurately stored and the binary - builds are repeatable. - - - Currently our source tree is built using three source repositories: - - JPMC : http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/ - Apache : https://svn.apache.org/repos/asf/incubator/qpid/ - JBoss : https://svn.jboss.org/repos/rhmessaging/store/ - - - To alleviate the headache of checking out the source from the correct branch of each repository we have - created a number of svn-external structures on the JPMC reposititory that pull together all the code in a - single svn checkout command. This simplicity doesn't come without pit falls. It is important to remember - that the code is still from each of the individual repositories and that svn commands will only affect the - repository of the current directory. For example if you are in the bdbstore directory an _svn commit_ will - only commit the bdbdstore code. This is what you would expect as _svn commit_ does not progress up the - directory tree. However, if you are qpid root and perform any svn command the bdbdstore and the - JPMC-distribution directories will not be included as they are not part of the Apache repository. The only - command that will affect all code is performing an _update_ in the top directory as checked out from the - svn-external location. It would update all three repositories. - - - - What now follows is a number of sections that cover source control process through the various development - phases. This docuement assumes that you are familar and have installed both a subversion client and maven. - Further details for these products can be found here: - Cygwin(LINK), Subversion(LINK), TortoiseSVN(LINK) and Maven(LINK) - - - - All Developers should have a local copy of all release performed by the team for support duties. This copy - should be located on the root of your windows machine due to the extremely long path values that will cause - svn to fail on a windows file system. - - - - Checkout the release sources - - - - This will pull down the sources for all the releases we have performed. (Since 2.1.0.4) Prior to this point - we - did not store the full source code internaly. - - -
- -
- Getting the initial source checkout. - - - The svn-external directories located in the JPMC NY subversion repsoitory: - http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/svn-external/ - - - Available svn-external checkouts - - v2.1.x - Corresponds to the Apache M2 branch - v2.2.x - Corresponds to the Apache M2.1 branch - v3.x - Corresponds to the Apache trunk - - - - - Perform the checkout - - -$svn co http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/svn-external/v2.2.x -]]> - - This will checkout the code from all three repositories with the cavet that you must login for the JBoss - repository - to get the BDBStore module. - You will need to have a JBoss account that has the correct permissions for the bdbstore component. - The rest of the code will still succeed if you don't. - - -
- -
- Building and developing the product. - - - Further details on developing and build process can be found here (LINK). But to validate your checkout you - should - can follow these steps: - - -$cd v2.2.x -$cd qpid/java -$mvn -]]> - - This will build the Apache java code base. When complete a final mvn will build the bdbstore: - - - - -
- - -
- Create UAT/Release repository - - - The code - must - come from a clean source so the previous step for getting the source must be - carried out as a pre-requisite to this step. - - - - This section explains the steps to bring the new release code into JPMC for UAT before release. If you are - peforming - a patch or additions to a previously released release then skip to the next section. - - - - AS: We shouldn't use tortoise for any of this, needs to be followable on Linux. - - I did: - - svn co http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/svn-external/v2.2.x - rm -rf `find -name .svn -type d` - cd v2.2.x - svn co -N http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/src - mv ApacheM2.1 src/2.2.1.0-rc1 - cd src - svn add 2.2.1.0-rc1 - svn commit -m 'Import 2.2.1.0-rc1 Source' - cd 2.2.1.0-rc1 - svn copy http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/src/2.1.0.7/java/JPMC-distribution/repos/2.1.0.7/ http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/src/2.2.1.0-rc1/qpid/java/JPMC-distribution/repos/2.2.1.0-rc1 - svn up - cd qpid/java/JPMC-distribution/DAM - ./build.sh 2.2.1.0-rc1 - cd ../DAM-client-slf4j/ - ./build.sh 2.2.1.0-rc1 - cd ../../../../ - svn commit -m # the POMS - cd qpid/java/JPMC-distribution/DAM - ./build.sh 2.2.1.0-rc1 - cd ../DAM-client-slf4j/ - ./build.sh 2.2.1.0-rc1 - - - - - - - - Check out current dev tree svn-external. : - $svn co http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/svn-external/v2.2.x - - Locate newly created checkout : $cd v2.2.x then $explorer . - - TortoiseSVN allows you to export this new repository so it can be added as a new source tree. - - - Right click and drag folder (ApacheM2.1) to your release src checkout the folder choosing 'SVN Export - All to - here' - This removes all .svn folders so it can be re-added to the NY SVN repository. - - Rename ApacheM2.1 to the next release number (2.2.1.0) - Right click on the new 2.2.1.0 source tree and select TortoiseSVN -> Add. This will add all the - new - files to svn. - - - Right click on the new 2.2.1.0 source tree and select Commit. Complete the commit log with the required - JIRA - ID. - This will commit the new files to the repository. - - - Open the repo directory src/2.2.1.0/qpid/java/JPMC-distribution/repos and the previous release - repo directory src/2.1.0.7/qpid/java/JPMC-distribution/repos. - - - Right click and drag the previous svn repository to the new release tree. - Select 'SVN Copy and rename versioned file here'. Enter the new release name '2.2.1.0' - - - Right click on the new 2.2.1.0 repo and select Commit. Complete the commit log with the required JIRA - ID. - This will commit the previous libraries to the repository. This ensures we can detect - ANY - library change between releases - - - The final step is to record the revision number of both the Apache and JBoss repositories. - - - - - These steps ensure that we have an accurate snapshot of the external code base. Incuding monitoring to - ensure - our - libraries have not changed. If you intend to create a build for testing you may skip the next section. - -
- -
- Extending a release into a DEV stage. - - This section explains how to setup the source to perform a patch or addition on a previously released - release. - If you need to bring new code into JPMC for UAT before release then skip to the previous section. - - - - When performing this you must ensure that you have a clean local copy the simplist way to do this is to - ensure the - output from a status is clean:$svn status - - - - - Using the TortoiseSVN repo-browser navigate to: - http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/src - - Locate the source tree that will be used as the basis for this new release (2.1.0.7) - Right click on the source that forms the basis and select 'Copy to...'. - Enter the new revision number (2.1.0.8) - Provide the correctly formatted commit log including JIRA ID. - - Using the repo-browser again navigate to the repo directory - src/2.1.0.8/qpid/java/JPMC-distribution/repos - - - Right click on the old repo 2.1.0.7 and select Rename. Enter the new release name '2.1.0.8' - - Provide the correctly formatted commit log including JIRA ID. - - You can now check out this dev tree using : - $svn co http://subversion.ny.jpmorgan.com/svn/repos/IBTAMQ/trunk/src/2.1.0.8 - - - - - These steps ensure that we have an accurate copy of a previously released code base. Incuding monitoring to - ensure - our - libraries have not changed. This DEV stage code solely located on the internal repository so there are no - concerns - about external code reviews or commiting code to a variety of repositories. - -
- -
- Create a build candidate - - Requires tidying up based on discussion with Chris Hardy from DEI. - - Each 'code line' contains the 'JPMC Distribution' which we use to create the required targets. As maven is - used to perform these builds we must store all the jars that it uses to perform the build. This will ensure - that we can accurately repeat the build process. - - - - Use svn copy to copy take a copy of the previous svn-repository, ensure that the copy is has the - correct name<version>-RC<number>, if this is a new RC simply rename the - previous RC. - - Update the file - VERSION - in the 'JPMC Distribution' directory - - Run the build script ('build.sh') located in the required package. - When the build successfuly completes check in the new RC build repository to ensure it can be - recreated. - - Ensure your repository is up to date. - Run the rebuild script ('rebuild.sh') to generate the final release artifacts. - - - Build outputs for use in JPMC - - - qpid-<version>.tgz - Server DAM package - - - qpid-<version>-client-slf4j.tgz - Client DAM package - - -
- - -
- Validate the build candidate - This is a vital step to ensure that valuable testing time is not lost. The newly built candiate should - have the following tests performed to validate the artifact created by the build process. The validate steps - vary depending on the artifact created. - - -
- Validating a Server DAM Artifact - - Copy package to unix server - - .tgz @noc-qpiddev01.jpmorganchase.com:. -]]> - - - - Move to unix server - - - - - - Unpack artifact - - .tgz -]]> - - - - Validate contents of bin directory - - - Validate all files bin files in bin directory are executable. - - - Ensure bin directory contains qpid_env.sh and qpid_env.csh - - /bin -msTool.sh qpid_env.sh qpid-run qpid-server.bat qpid.start qpid.stopall run.bat -qpid_env.csh qpid-passwd qpid-server qpid-server-bdb.bat qpid.stop runAll run.sh -]]> - - - - Validate all files bin directory have unix line endings. - - - A suitable grep will do the trick. Only .bat files should be listed. - - - - - - - - - - Validate the build location was clean. - - Check contents of SVNREV.txt - - - - Note that the svnversion number is a single number. - - - Check contents of Qpid jars - - - - Note again that the svnversion number is a single number. This should be repeated for all qpid - jars. - - - - - Ensure the number of libs has not increased due to a dependency change. - - - - If the number has changed then explain the change and update this document. - Count 33. (Version:2.1.0.4). - Count 20. (Version:2.1.0.7). Removed un-used transitive dependancies pulled in via maven. - - - - Add new artifact location to softdefs - - > .softdefs -qpid:~:qpid- - -$ cat .softdefs -jdk:/home/release/pyrsyrel/TechRefresh/opt/jdk:1.5.0.08 -qpid:/home/pyramid/e151839/releases/:qpid-2.1.0.4 -]]> - - Ensure that you only have one line startingqpid. You may have more entries - such as - jdk - here, these are not required. - - - - - Attempt to load qpid - - /qpid- -]]> - - The echo should show the full path to the directory of the DAM artifact to test. - - - Test qpid.start - - - - Background this process (ctrl-z, $ bg) and test the stop methods. - - - Test qpid.stop - - - - Restart the broker for the stopall test - - - Test qpid.stopall - - - - - - - - Test start broker directly works - - - - - The broker should start up with no errors and report that it is ready. - - - - Ensure broker will start with delivered config files. - - $ ./qpid-server -c ../etc/transient_config.xml - $ ./qpid-server -c ../etc/persistent_config.xml - - The output should not report any errors and as with the default config should report the broker is - Ready. - - - -
- -
- Validate Management - - - Unpack JMX Management console - On a local windows machine unpack qpid-management-<version>.zip - - - - Validate JMX management console connects - - Start remote broker with the default configuration (./qpid-server) - Launch application qpidmc/bin/qpidmc.bat - - Create a new connection. Click: - - - - - - Green plus(+) symbol - - - - Enter server details for remote linux broker from above tests, log in as guest(guest) - - - Ensure that the following items are available and browseable. - - org.apache.qpid : UserManagement - org.apache.qpid : Virtualhosts - - - - - - - - Validate Secure JMX management console connects - - Start remote broker with the persistent configuration (./qpid-server - - ../etc/persistent-config.xml) - - Unpack qpid-management-<version>.zip - Launch application qpidmc/bin/qpidmc-secure.bat - - Create a new connection. Click: - - - - - - Green plus(+) symbol - - - or use reconnect : - - - - - - Yellow arrow(->) symbol - - - - Enter server details for remote linux broker from above tests, log in as admin(admin) - - - Ensure that the following items are available and browseable. - - org.apache.qpid : UserManagement - org.apache.qpid : Virtualhosts - - - Reconnect to the server with the linux broker from above tests, with log in as - guest(guest) - - Ensure that 'org.apache.qpid : Virtualhosts' is available and browseable. - Ensure that 'org.apache.qpid : UserManagement' is not accessable. - - - - - Validate jconsole connects - - Start remote broker with the default configuration (./qpid-server) - Launch Jconsole from your local JDK installation - Use the remote host option and fill in details server as before and user guest(guest) - - - Ensure that the following MBeans are available and browseable. - - org.apache.qpid : UserManagement - org.apache.qpid : Virtualhost.Exchange - org.apache.qpid : Virtualhost.Queue - org.apache.qpid : Virtualhost.VirtualHostManger - - - - - - -
- -
- Validate the client DAM candidate - - Copy package to unix server - - -client-bin.tgz @noc-qpiddev01.jpmorganchase.com:. -]]> - - - - Move to unix server - - - - - - Unpack artifact - - -client-bin.tgz -]]> - - - - Validate contents of bin directory - - - Validate all files bin files in bin directory are executable. - - - Ensure bin directory contains qpid_env.sh and qpid_env.csh - - -client/bin -qpid_env.csh qpid_env.sh -]]> - - - - Validate all files bin directory have unix line endings. - - - A suitable grep will do the trick. Only .bat files should be listed. - - - - - - - - - - Validate the build location was clean. - - Check contents of SVNREV.txt - - - - Note that the svnversion number is a single number. - - - Check contents of Qpid jars - - - - Note again that the svnversion number is a single number. This should be repeated for all qpid - jars. - - - - - Ensure the number of libs has not increased due to a dependency change. - - - - If the number has changed then explain the change and update this document. - Count 11. (Version:2.1.0.7). - - - Run Pub / Sub example - - This should be updated with the 2.2.1.0 to use the simple examples. The example package - should also ship with slf4j-simple.jar - - - - - Start remote broker with the default configuration (./qpid-server) - Run the Subscriber - Run the Publisher - The publisher should then send message numbers 0-99 and the subscriber should receive - 0-99. Both clients quit when their task is complete. - - - - - - - - Run Point to Point example - - - Start remote broker with the default configuration (./qpid-server) - Run the Simple Test - The will send and receive a message. - - - - - - - -
- -
-
- - -- cgit v1.2.1