Who is Responsible for Integrating JSR-314 JavaServer Faces into GlassFish? The following Oracle employees
- Edward Burns
- Sheetal Vartak
- Roger Kitain
Most Recently Integrated Version of JSR-314 Implementation On 20110127, Ed Burns integrated version 2.1.0-b11 of Mojarra into GlassFish. The SVN url for this version is <https://svn.java.net/svn/mojarra~svn/tags/2.1.0-b11>. This corresponds to the following SVN tag. Maven Repository Information
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1.0-b11</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.1.0-b11</version>
<scope>provided</scope>
</dependency>
Integration Process There is a multi stage integration process. Stage 1: Build and verify correctness of Mojarra 2.1 HEAD
- Check out a fresh mojarra HEAD branch (https://svn.java.net/svn/mojarra~svn/trunk), configure the build.properties to point to a known-good installation of GlassFish 3.1, and run ant -Dbuild.number=DATE-TIME clean main test.with.container.refresh. Replace DATE-TIME with today's date an the current time, for example, 20100804-2321. This is not required but it does put information into the server log verifying that you are, in fact, running the expected Mojarra bits. Instructions on doing this may be found in the Mojarra FAQ. Look for "automated tests"
Stage 2: Build and verify correctness of GlassFish 3.1 HEAD
- Run the quicklook tests. There are instructions for this elsewhere, but we reproduce the highlights here.
- When the GlassFish 3.1 build successfully completes, cd to distributions/glassfish relative to the GlassFish 3.1 source root.
- rename the freshly built target directory to have today's date and time. This is just a precautionary measure. For example target-20100716-1854.
- cd to your freshly renamed target directory
- unzip glassfish.zip
- cd glassfishv3 and note the current directory, obtained via the pwd command. For example /home/ejburns/Documents/JavaEE/workareas/glassfish-1HEAD/distributions/glassfish/target-20100716-1854
- cd to the root of your GlassFish source workarea and then cd v3/tests/quicklook
- run mvn -Dglassfish.home=$GLASSFISH test where $GLASSFISH is the fully qualified path from two steps ago.
- CAREFULLY scrutinize the output to ensure that the tests all passed successfully. If not, the integration cannot proceed until they do.
Stage 3: Install Mojarra 2.1 HEAD into GlassFish 3.1 HEAD and Verify Both
- Modify Mojarra HEAD workspace local build.properties file to point to glassfish home from Stage 2. Re-run ant -Dbuild.number=DATE-TIME main test.with.container.refresh. Replace DATE-TIME with today's date an the current time, for example,20100804-2321. As a side-effect, this will install the latest Mojarra jars into the GlassFish HEAD.
- Re-run the quicklook tests starting with step 6 from Stage 2.
- If both sets of tests complete successfully, without failure, start the glassfish server manually and visit the admin GUI.
- If the admin GUI comes up successfully and basic operations can be performed, you can proceed to Stage 4.
Stage 4: Update Version Numbers, Commit, and SVN Tag Mojarra 2.1 HEAD
- If necessary update the version numbers in common/ant/common.xml. This is seldom necessary.
- Update the version number in jsf-tools/pom.xml to correspond with common/ant/common.xml
- Update the version number in updatecenter2/conf/jsf_proto.py . For example, if you are building 2.1.0-b09 you would make the file have this in it: "version" : "2.1.0,0-9",
- svn commit the modified version files.
- svn tag the HEAD using the following naming convention:
svn copy https://svn.java.net/svn/mojarra~svn/trunk \
https://svn.java.net/svn/mojarra~svn/tags/2.1.0-b09 \
-m "Tag 2.1.0 Build 09"
Replace b09 and Build 09 with the appropriate build number. Stage 5: Push jsf-api.jar and jsf-impl.jar to java.net so the GlassFish Build Can Depend On Them
- svn checkout the source from the tag created in Stage 4. Edit build.properties as usual, setting the jsf.build.home, container.name, and container.home properties correctly. Point to the GlassFish 3.1 HEAD build from Stage 2.
- Run ant main -Dbuild.type=FCS -Dbuild.number=b09 container.deploy to get the jars pushed into the GlassFish 3.1 HEAD build
- Re-run the quicklook tests as a sanity check.
- Do a test run of generating the maven artifacts for jsf-api and jsf-impl.
- cd jsf-api; ant mvn.deploy.promoted.local -Dbuild.number=b09
- cd jsf-ri; ant mvn.deploy.promoted.local -Dbuild.number=b09
- Naturally, replace b09 with the build number from the tag.
- Inspect the jsf-api and jsf-impl artifacts that were pushed into your local repository. Look at the build output to find where they end up. For example,
[INFO] Installing /Users/edburns/Documents/JavaEE/workareas/mojarra-2HEAD/jsf-api/build/mvn/target/jsf-api-2.1.0-b09.jar to
/Users/edburns/.m2/repository/com/sun/faces/jsf-api/2.1.0-b09/jsf-api-2.1.0-b09.jar
In particular, look at the .pom files and make sure everything looks right.
Stage 6: Modify glassfish build files to point to the just published maven jars
- Remove the jsf-api and jsf-impl jars from your local maven repository. For example
- rm -rf ~/.m2/repository/com/sun/faces
- In your GlassFish 3.1 HEAD workspace open the top level pom.xml and update the contents of the <jsf-api.version> and <jsf-impl.version> elements to be consistent with the just published maven jars.
- In the same workspace, edit the file packager/resources/pkg_conf.py and update the jsf_version property. For example, if you were pushing 2.1.0-b09, the property would be jsf_version="2.1.0,0-3".
- svn update, clean, and rebuild your GlassFish 3.1 HEAD workspace.
- Repeat Stage 2 with this new build.
- If the quicklook tests succeed, you are ready to proceed.
Stage 7: Obtain Permission to Commit the Integration, Commit the Integration Send the pom review request to dev@glassfish.java.net. Please consider using this format for the email.
Subject: pom.xml review request: integrate JSF 2.1.0-b09
This change-bundle integrates JSF 2.1.0-b09. I have run the quicklook
tests with these jars pulled fresh from maven to a local repo that does
not have any com/sun/faces directory and the tests ran successfully to
completion.
I have also brought up the adminGUI web application (as this exercises
on the new JSF version). It worked just fine.
SECTION: Diffs
Index: pom.xml
===================================================================
--- pom.xml (revision 42527)
+++ pom.xml (working copy)
@@ -104,8 +104,8 @@
<el-impl.version>2.2.1-b03</el-impl.version>
<jstl-impl.version>1.2</jstl-impl.version>
<jstl-api.version>1.2</jstl-api.version>
- <jsf-api.version>2.1.0-b06</jsf-api.version>
- <jsf-impl.version>2.1.0-b06</jsf-impl.version>
+ <jsf-api.version>2.1.0-b09</jsf-api.version>
+ <jsf-impl.version>2.1.0-b09</jsf-impl.version>
<jsf-ext.version>0.2</jsf-ext.version>
<woodstock.version>4.0.2.6</woodstock.version>
<jaxrpc-api.version>1.1</jaxrpc-api.version>
Index: packager/resources/pkg_conf.py
===================================================================
--- packager/resources/pkg_conf.py (revision 42527)
+++ packager/resources/pkg_conf.py (working copy)
@@ -64,7 +64,7 @@
felix_version="3.0.5,0-0"
javadb_version="10.5.3.0,0-0"
corba_version="3.1.0,0-12"
-jsf_version="2.1.0,0-6"
+jsf_version="2.1.0,0-7"
grizzly_version="1.9.21,0-1"
metro_version="2.1,0-17"
javahelp_version="2.0.2,0-1"
Once you have received approval, commit the changes. Please consider using the following as the changebundle.txt file in your commit command. svn commit -F changebundle.txt pom.xml packager/resources/pkg_conf.py
Integration of JSF 2.1.0 b09 into GlassFish 3.1 HEAD http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/JSF+2.1+Schedule
r=janey
MODIFIED FILES
pom.xml
packager/resources/pkg_conf.py
Stage 8: Watch Hudson Like A Hawk to Ensure You Didn't Break The Build The hudson URL to watch is http://gf-hudson.us.oracle.com/hudson/view/GFv3%20Trunk/job/gf-trunk-build-continuous/. If the build breaks, get right on top of it and revert your changes. Stage 9: Update this page with the new build information, names and dates. If Performing A Formal Release, do the following Stage 10: Relnotes Search the commit logs to generate a list of issues fixed during this release. For example.
svn log -r \{2009-07-02\}:8830 > log-2009-07-02-8830.txt
grep -v "^[-+]" log-2009-07-02-8830.txt | grep -v "^@" | grep -v "^r" | grep ".*[0-9].*"
This will get all the commit log messages from 2 July 2009 until revision 8830, cat them to a file, and then output all the lines in the log that have a number in them, excluding the revision number line and lines in diffs. Stage 11: publishing the release to maven
ant clean -main -Dbuild.type=FCS
cd jsf-api
ant mvn.deploy.release.local
Inspect the jars, particularly the manifest, to make sure all the OSGi information is correct. The string SNAPSHOT must not occur any where in the jar file name itself or in the manifest. For example, for 2.1.0, the jar file name is jsf-api-2.1.0.jar. If everything looks ok, do the same in jsf-ri and check that jar and its manifest too. If that is ok also, go back to jsf-api and run the mvn.deploy.release target. Once it deploys to the repo, do the same for jsf-ri. For Mojarra 2.0.X releases Make sure you build Mojarra with Java 5 since it must also run on Java 5. |
