dev@glassfish.java.net

Status of the builds

From: Bhakti Mehta <Bhakti.Mehta_at_Sun.COM>
Date: Wed, 09 Jul 2008 15:26:55 -0700

Here is a status of the v3 builds
The glassfish-v3 http://hudson.sfbay/view/GFv3/job/glassfish-v3/ is now
blue
The quicklooks http://hudson.sfbay/view/GFv3/job/v3-quicklook/ are
*_passing._*
Dev builds http://hudson.sfbay/job/glassfish-v3-devbuild/ and
http://hudson.sfbay/job/v3-dev-builds-quicklook/ are blue

The following problems occurred and were resolved to get the build to
work :

1. 401 authorization issues:
http://hudson.sfbay/view/GFv3/job/javaee-api-repackaging-Sahoo/10/console
builds javaee-api and publishes out the artifacts.
There were issues related to 401 authorization which is resolved by
adding the repository id. The artifacts are pushed to an internal
staging repository rator.sfbay from where they get deployed to external
repos.
*Solution:* So if you have a job that deploys to rator. You need to have
mirror-glassfish-repository as an downstream project

2. Concurrency issues
Once the javaee jars get pushed out the main v3 build gets kicked in, we
ran into multiple issues there was concurrency as SimpleDateFormat is
not threadsafe. There was another issue with forked processes failing
to exec on solaris.
Thanks to Kohsuke for all his help with these issues.

3. Failures in QL
Next the quicklooks get kicked in. We had failures in quicklooks due to
jspimpl needing to be built with 0.3.8 of hk2. Thanks to Kin-Man for
updating that.

4. Warnings on starting server
We still see warnings on starting the server and I see another thread by
Hong about that but that does not impact the build or quicklooks in anyway.

Arun was trying to push the jruby but has some issues which need to be
addressed regarding the version of jruby. He can follow up with more
details

5. Network slow
There are issues with the network being slow and that was causing the
v3-devbuild to timeout and v3-dev-quicklooks to fail. We increased the
number of apache processes from 150 to 300 on wsinterop.sfbay
We are trying to see if we can get some data from the webserver forks
based on the monitoring data we have obtained.
I am also trying to bypass the wsinterop machine and see how it will
help speeden our builds.
Finally we are also discussing about setting up Nexus but that needs to
be setup internally and externally so that still needs to be figured.

Please do not make commits and expect the build team to fix all the
issues. It would be deeply appreciated if you could communicate to us
(build team and module leads) ahead of time if there are major changes
to versions especially since some components are built outside the v3
workspace and have meetings with the module leads to lead to resolution
on these changes.

Any other suggestions to better improve this process of checkin will be
appreciated.

Regards,
Bhakti