Kedar Mhaswade wrote:
> 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.
The maven way of doing things is for each module to build its own jar
and put it back to the repository.
The dependency descriptor in POM takes care of assembling all those
million small jars into classpath from the local repository, when you
launch a program for debugging. So that doesn't require any human
intervention anyway. AFAICT it's OK to generate classes in
${glassfish.home}/<module>/target/classes.
> Bottom line: *Assembly* of appserv-*.jars is something that should be a
> separate step. Developers will be happy.
I agree. I don't see why you need to pack multiple modules into a single
jar when developing.
It makes sense to have a separate packaging mode that produces the
actual image.
(But I'm sure packaging interacts with classloading, and I don't know
much about Glassfish code base anyway, so I could be wrong.)
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com