Glassfish 4 admin console class loading issue when built from source

I seem to have some kind of class loader problem with the admin web application after building from the most recent trunk source.
The default domain starts without error. Attempting to access the admin application fails with the root cause being failure to locate com.sun.webui.jsf.faces.UIComponentELResolver.
The class in question exists within $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/extra/webui-jsf-4.0.2.10.jar and was compiled using the same JDK I am using to start the container.
Moving that jar to $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/lib/ circumvents the immediate issue but introduces/exposes new ones.

Stack trace excerpt:

[2014-04-16T19:10:31.578+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=114 _ThreadName=Thread-20] [timeMillis: 1397639431578] [levelValue: 1000] [[
Critical error during deployment:
com.sun.faces.config.ConfigurationException:
Source Document: jndi:/__asadmin/WEB-INF/faces-config.xml
Cause: Unable to create a new instance of 'com.sun.webui.jsf.faces.UIComponentELResolver': javax.faces.FacesException: com.sun.webui.jsf.faces.UIComponentELResolver
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:353)
at com.sun.faces.config.processor.ApplicationConfigProcessor.addELResolver(ApplicationConfigProcessor.java:592)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:304)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:116)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5394)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5932)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:211)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
Caused by: javax.faces.FacesException: com.sun.webui.jsf.faces.UIComponentELResolver
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:278)
... 25 more
Caused by: java.lang.ClassNotFoundException: com.sun.webui.jsf.faces.UIComponentELResolver
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1783)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1633)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at com.sun.faces.util.Util.loadClass(Util.java:325)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 26 more
]]

I am running the container distribution found at ${SOURCE_ROOT}/main/appserver/distributions/glassfish/target/glassfish.zip after running 'mvn clean install' from ${SOURCE_ROOT}/main.
The latest 4.0 distribution from glassfish.java.net does not exhibit this behaviour when run on the same JVM.
I have rebuilt 3 times, completely removing my local maven repo for the last 2 builds with identical results each time. I built using gfbuild.sh too - same result which shouldn't surprise as it just invokes 'mvn $@' anyway.
The only change I have made to the source was to add the following to the shell scripts in ${INSTALL_ROOT}/bin/ to allow invocation from symbolic links in /usr/local/bin:

function realpath {
local r=$1; local t=$(readlink $r)
while [ $t ]; do
r=$(cd $(dirname $r) && cd $(dirname $t) && pwd -P)/$(basename $t)
t=$(readlink $r)
done
echo $r
}
AS_INSTALL=$(dirname $(realpath "$0"))/../glassfish

The attached diff is between the downloaded and locally built distributions.

My environment:
Mac OS X 10.9.2

dwhitla@raptor:~$ java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
dwhitla@raptor:~$ mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 23:51:28+1000)
Maven home: /opt/local/share/java/maven3
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: utf-8
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"

Does anyone have any idea what is causing this?

Thanks,

Dave