Home Index Changes Prefs Log in »
View Attach (2) Info

Table of Contents

Source Repository Information

The UC 2.0 project uses http://updatecenter2.dev.java.net for source code control and issue tracking. UC 2.0 has a subversion source repository as opposed to UC 1.0's repository. (Historical note: The need to have a subversion repository forced the creation of a separate project to get such a repository.)

Browse the source

Build orchestration

UC 2.0 main build tasks typically only need to perform general build orchestration. Various general and python based build tools were evaluated and Apache Aant , a Java-based generic build sequencer was selected. For the 2.0 release, Ivy was used for dependency management, but since the B16 build, Ivy is no longer used and dependencies are checked into the source tree.

Repository layout

Note:

  • These directories are proposed names. They won't be created unless they are really needed at some point in development.
  • The external runtime dependencies (under external dir) are built separately. The resulting binaries are checked into the dependencies directory in the source tree. To decide where to draw the line concerning what should be done in the external area vs. what should be done in the project area, consider these factors:
    • The build in the project area is completely automated and run nightly. The builds in the external area are done manually as needed, and only when there is a new version of the component available. If packaging or creation of the external component for use by Update Center requires manual steps, make that part of the external area and then check the result into the dependencies area.
    • Operations that are specific to how Update Center works should be made part of the project area. Any design decision that we make within Update Center should not cause a repackaging of a component from the external area. Of course, this excludes decisions about what external components and which versions are used.
  • Each module has its own unit tests. The tests are not executed as part of the update center build but can be executed from the module and from top level (for nightly build?).
  • Update center build creates in-tree build under top level "dist" directory with the appropriate file structure (similar to "maven setup" from UC 1.x). During development, the tool can be run from here.
  • System tests are under system-tests directory. These tests can be compiled and executed seperately.
  • The build.xml creates the final image for distribution. 
trunk/
  www/
      repository/                   - maven repository for binaries (no longer used)

  project/
    README.txt
    build.xml
    build/              - build output
    dependencies/       - binary dependencies from external area
    docs/
    tools/              - build scripts, custom ant tasks etc.
    updatetool/         -
        src/
         ...
        tests           - unit tests
    bootstrap/          - bootstraps ips into an image
        src/
          java/
        build/
    pkg-java/
        src/
          java/
        build/
    tests/              - examples of how to use UC

  external/
    ips/                - publishes to maven manually
        README.txt
    python/             - publishes to maven manually
        README.txt
    wxPython/           - publishes to maven manually
        README.txt
    gettext/            
        README.txt      - Instructions on obtaining or building the tools yourself

Dependencies

Update Center 2 includes several dependencies. Instructions for obtaining and building these dependencies for the various platforms can be found in the external part of the source repository. These build instructions result in producing a JAR file for each dependency which is then checked into the project/dependencies directory and from there it is used for the build.

In addition to the README files that are including in the external source tree, some dependencies also have additional wiki pages to help with building:

Commits

To see every commit that is done to the updatecenter2 workspace, subscribe to the commits@updatecenter2.dev.java.net alias.

Changing the Product Version

After the product is released or branched the version number will need to be changed. Also each promoted build may need the build number incremented. Follow the steps listed in Managing UC2 Versioning for details about how to update version numbers and other release specific changes that may be necessary.

Simple Build

This section describes how to build Update Center 2.0 without the use of NetBeans. See the next section if you do want to use NetBeans.

Prerequisites

  1. Ensure that Subversion client support is available on your system.
  2. Ensure that you have ant 1.7.0 or later.
  3. Ensure that you have GNU gettext tools 0.17 or later.

Checkout and Build

To checkout the source from the trunk and build the project, do the following: 

C:\> svn checkout https://updatecenter2.dev.java.net/svn/updatecenter2/trunk/project uc2 --username guest
(Note: There is no password for the guest user. Just press enter at the password prompt.)
C:\> cd uc2
C:\uc2> ant all
To check out the source from a branch - the version 2.2 sustaining (or update) branch in this case – use the below checkout command and perform the build steps as in the above example. 
C:\> svn checkout https://updatecenter2.dev.java.net/svn/updatecenter2/branches/2.2sustaining uc2 --username guest
To check out external depndencies, use this checkout command: 
C:\> svn checkout https://updatecenter2.dev.java.net/svn/updatecenter2/external external --username guest

At this point, the product has been built under dist/build. To run the updatetool GUI, execute the following (on Windows): 

C:\uc2> build\dist\windows-i386\bin\updatetool

Building Using NetBeans

The Update Center 2.0 workspace includes a NetBeans project file that assists with doing development using NetBeans. Here are step by step instructions for building and running the project using NetBeans:

Prerequisites

  1. Ensure that Subversion client support is available on your system.
  2. Download and install NetBeans 6.0.
  3. Configure NetBeans to point to Subversion client (necessary on Windows)
    • Tools -> Options -> Miscellaneous -> Subversion
    • Fill in the location of the Subversion client
  4. Add the following modules to NetBeans:
    • Subversion (find this in Tools -> Plugins, Available modules). It might already be installed.
    • jpydbg Python support (optional - makes editing python code easier). Use the "Downloaded" tab within Tools -> Plugins to install the downloaded .nbm file.

Checking Out the Source

  1. Select Versioning -> Checkout from the menubar.
  2. Enter https://updatecenter2.dev.java.net/svn/updatecenter2 for the Repository URL and you java.net username and password. Click Next.
  3. Enter trunk/project for the Repository folder and a local folder name for Local Folder. Since the folder that will be checked out will be called "project" it is good to name this local folder in a way that will identify this as belong to Update Center 2.0, such as "uc2". Make sure the "Scan for NetBeans projects..." checkbox is checked. Click Finish.
    • Use "guest" for anonymous access.
  4. Click the Open Project button after the checkout is complete.

Building and Running the Project

At this point the project is checked out and you should have an Update Center 2.0 project available in your projects pane. To build and run the project, click on the green "play" button in the tool bar or press F6. This will build the project and run the updatetool program.

Going forward, you can start the GUI by expanding the "build.xml" item under the Update Center project, right-clicking on the "run-updatetool" and selecting the "run target".

Updating the Source

Henceforth, to get an updated copy of the source, right click on the Update Center 2.0 project and select Subversion -> Update.

Builds

Nightly Builds and Status Monitoring

UC2:

/net/jwsre.sfbay/n/v14/updatecenter2-trunk/builds/yyyy-mm-dd_HH-MM-SS/archive (Sun Internal only)

http://jwsre.sfbay/hudson/job/updatecenter2-trunk (Sun Internal only)

UC2 IPS: (Sun Internal only)

/net/jwsre.sfbay/n/v13/ips1.0/configurations/axis-label/<platform>/builds/yyyy-mm-dd_HH-MM-SS/archive (Sun Internal only)

http://jwsre.sfbay/hudson/job/ips1.0 (Sun Internal only)

Request a Build

Note: Each time you click on one of the the following links, a build will be scheduled on the hudson server for the respective product.

UC2 Trunk (Sun Internal only)

UC2 Sustaining (Sun Internal only)

UC2 IPS (Sun Internal only)

UC2 IPS Gate (Sun Internal only)

Promoted Builds

http://koori.sfbay/java/re/updatecenter/2.0/promoted (Sun Internal only)

http://download.java.net/updatecenter2/promoted

Procedure for Promoting a Build

The plan that is developed for a release has a promoted build schedule with a promoted build being done every 2 or 3 weeks. The build promotion process typically starts on Monday morning. Here is the procedure for promoting a build (from the development perspective):
  1. Notify dev@updatecenter.dev.java.net that the workspace is frozen
  2. Look at the latest nightly build from hudson which was automatically installed into the nightly build repository at 2am PT.
  3. If there was a nightly build that occured after 2am PT, or if there is a nightly build in process wait for it to complete, then run /export/IPS/UC20-nightly/updatecronjob.sh to install the build into the nightly build repository
  4. Perform sanity testing. Communicate to the team that the build candidate is available. Check whether all issues for the build have been resolved.
  5. Come to a consensus with the team that the build is ready to promote. This may require additional respins, additional sanity testing, iteam meetings, etc.
  6. Send e-mail to RE (Jason) requesting that the build be promoted. Include the hudson build number and the SVN revision number. The RE promotion will get the build to the java.net download area, the maven2 artifacts published, and the build into the SWI development repository.
  7. Update the updates.sfbay promoted build repository. This is done by running /export/IPS/UC20/update.sh. It may be necessary to make sure the /export/IPS/latest-nightly symbolic link is pointing at the right build.
  8. Update the version.properties file in the source code to have the next build number.
  9. Once RE promotion is complete, do the following:
    1. Update the ipshowto.org download page to point to the new build
    2. Publish a blog entry on blogs.sun.com/uc2 announcing the availability of the new build
    3. Send a message to users@updatecenter.dev.java.net announcing the availability of the new build
    4. Update the release plan page to indicate that the build is completed

Procedure for Promoting a Release

This process starts when a GO is given for a release, either by PAC(s) (for major/minor releases) or by QA (for update releases).
  1. Request RE (Jason) to submit a PPR for the release.
  2. Request RE (Jason) to promote the build (by build number) as a release build. This means it will show up on download.java.net. This doesn't involve publishing any new packages to the repos as the packages are already there.
  3. On the ipshowto.org downloads page, update the appropriate column to point to the new release with a new release date and new release name.
  4. Verify with doc writer (Mike) that the release notes have been updated with information about the release.
  5. Publish a blog entry for this release on blogs.sun.com/uc2
  6. Send a message to users@updatecenter.dev.java.net with a pointer to the blog entry

Procedure for Publishing the Maven Plugin
There are instructions for publishing the maven plugin on a separate page. This is only done when the plugin actually changes.

Example Installation (Sun Internal only)

To update a running set of repositories with the latest automated build, do the following:

  1. Login to updates.sfbay - see a project team member for credentials.
  2. /export/IPS/UC20/update.sh

A set of repositories that is automatically updated with each nightly build is available on updates.sfbay in the /export/IPS/UC20-nightly directory. These repositories run on ports 10031-10035. The initial gfv2.zip download file can be downloaded from http://updates.sfbay/UC20-nightly/gfv2.zip. A cron job runs at 2am PT each day to update these repositories with the latest build.

To install the output from the latest build on the SWAN updates.sfbay server using a set of fresh repositories, do the following.

  1. Login to updates.sfbay - see a project team member for credentials.
  2. The examples are installed under /export/IPS with a separate directory for each build. If the desired directory is already there, then remove it. Remember to stop any python processes that might be running against that directory. Then create the desired directory.
  3. Unzip /export/IPS/latest-nightly/example2.zip to the desired directory.
  4. Run sh startexample2.sh in the desired directory.

Development IPS Repositories

The following IPS repositories are maintained on a Sun internal server named updates.sfbay.

Platform values are:

  • windows
  • mac
  • linux
  • solaris-x86
  • solaris-sparc
Multi-Platform Repo URLPlatform-specific Repo URLRolepkg.depotd Ports
http://updates.sfbay/dev/promoted/http://updates.sfbay/dev/promoted/platform/Most recent promoted buildwindows 10021
solaris-x86 10022
solaris-sparc 10023
linux 10024
mac 10025
http://updates.sfbay/dev/latest/http://updates.sfbay/dev/latest/platform/Nightly or most recent dev build from Hudsonwindows 10031
solaris-x86 10032
solaris-sparc 10033
linux 10034
mac 10035
http://updates.sfbay/gfv3tp2/http://updates.sfbay/gfv3tp2/platform/GF V3 TP2 test repowindows 18821
solaris-x86 18822
solaris-sparc 18823
linux 18824
mac 18825
http://updates.sfbay/opends/http://updates.sfbay/opends/platform/OpenDS experimental repowindows 11121
solaris-x86 11122
solaris-sparc 11123
linux 11124
mac 11125

PyWinAuto automation tool : Tool to automate GUI applications on Windows (Applicable for updatetool and SW Update Manager)

How to install it

1. Install python2.4

2. Download pywinauto from http://sourceforge.net/projects/pywinauto/files/

3. Install Ctpyes. Use the following URL to download it : http://sourceforge.net/project/showfiles.php?group_id=71702

4. Install SendKeys using the fllowing URL : http://www.rutherfurd.net/python/sendkeys/index.html

5. Install PyWinAuto module :

5.1 : Extract Pywinauto zip file

5.2 : Go to \pywinauto-0.3.8

5.3 : Launch the setup.py

Example : c:\Python24\python.exe setup.py install

This allows to import the PyWinAuto module to Python

6. Apply the following workaround for an issue discovered with PyWinAuto that results in a Traceback

after launching the updatetool

open the file :

C:\Python24\Lib\site-packages\pywinauto\application.py

Go to the line 922

Replace the line

if result == WAIT_TIMEOUT

by the line

if result == win32defines.WAIT_TIMEOUT

7. You are now ready to use PyWinAuto

and also, corrrect return false to return False

Link Purpose
http://pywinauto.openqa.org Pwwinauto web site
http://clearspace.openqa.org/community/pywinauto Forum for PyWinAuto
http://pywinauto.blogspot.com/ The PyWinAuto creator blog

GUI Sanity Testing automation on Windows

Test ID PUrpose Automation Status on Windows
updatetool_Sanity_01 Launches updatetool and invokes the About Automated
updatetool_Sanity_02 Launches updatetool from an image , For this active image the toolkit is already installed
Uninstall pkg-extra-tools package
Reinstall pkg-extra-tools package
Exits Updatetool		 In Progress
updatetool_Sanity_03Launch updatetool
change preferences from no proxy to using the proxy
Do a Refresh		 Not yet started
updatetool_Sanity_04 Launch updatetool
Create a new user image
install a component into that user image
Close the User Image 		Partially automated, need to add the User Image closing
SWUM_Sanity_01 Launch SW Update Manager and apply all updates Automated
« Home Attachments Info Index Changes
This page (revision-94) was last changed on 28-Oct-09 09:43 AM, -0700 by TomMueller