>It is also non-standard the way the Glassfish build unpacks and copies
>around external jars as part of the build. I keep meaning to take some
>metrics on the build, but it _feels_ like the build spends 80% of its
>time updating the [15 MEG] appserv-rt.jar. That just can't be healthy.
>
>
Right.
AFAIK, the basic reason for this non-standard way where GlassFish build
updates the jar(s) that it (build) depends on compilation is to ease the
developers by not having to worry about whether their newly built
classes take effect. Remember, there is configure-runtime step that
creates a default domain that has the same appserv-*.jars in their
classpath and developer can *quickly* test their changes on the default
domain.
appserv-rt.jar happens to be the worst update candidate for its size.
And I think we had this in mind that having to update such a *huge* jar
is quite inefficient and should be removed when we enhance the build.
Note that you don't find this as a problem with other jars, for they are
small in size.
A suggestion I had was to build *all* the GlassFish classes at one place
${glassfish.home}/classes and then refer to this location in the
development environment (default domain). The configure-runtime step can
set up the domain.xml (classpath-prefix) and server.policy for the
default domain that way. In principle, this is much better than every
module creating classes in their private area and/or updating mammoth
jar files. Note: If GlassFish build defies the Java package separation
and has multiple copies of the same class name, we have a bigger problem.
As an added advantage, the cleanup step becomes easy as it just has to
delete the classes directory.
Bottom line: *Assembly* of appserv-*.jars is something that should be a
separate step. Developers will be happy.
Kedar