Hi, Matthew:
I think you again are right on target. I agree with all of what you've
said. A pure ant or maven (my vote goes for maven) is a no brainer
decision. So the rest of my email will not address which tool we should
use to build.
At the beginning of setting up the glassfish build, we considered the
drawbacks you listed below and prototypes solutions. As you know by
now, some of our solutions had to give in to all kinds of constraints.
I'd like to bring up those contraints again. Given our priority now is
to attract more developers to the glassfish community, maybe some of the
constraints we had to deal with before could take a back seat this time
around. If true, hopefully we are more free to consider the possible
solutions going forward.
* About the non-standard way the glassfish build has to unpack/copy jars
Constraints:
1. The appserver image was a given, i.e. whatever files that used to be
there have to be there, no more, no less. This is because the appserver
was shipped in Solaris 9 (and onwards). The solaris packaging requires
a finely controlled file content. You can think of it as a manifest of
file list. If there are files missing, the solaris packaging will
break. If we were to mess with the number or the name of the jars, we
need to know how we can support the upgrade senario for the Soaris packages.
2. Many scripts already written depend on the appserver image. If we
were to change that, we will have a lot of unhappy users.
* About the individual modules updating appserv-rt.jar
Constraints:
1. The pre-glassfish build used to build individual jars within the
module. There is a post build process that collects all jars and
assemble them into the appserver image. The drawbacks are:
a) It takes a long time to do the post assembly.
b) People have complained it is too much effort to update just one
class in the server image, i.e. you'd have to do the module build,
either manually update the appserv-rt.jar yourself or add the build
directory to the system classpath. Neither is elegant and fool proof.
Hence the alternative in glassfish....
* About each module pulling their own dependencies (not listed as your
concern, but since I am on a roll here....)
Constraints:
1. It was just easier to manage all the 3rd party dependencies, i.e.
what they are, what's the version etc etc etc. We haven't had any
precedence of shipping more than 1 version of the same components.
Having individual modules define which binary/version they want to use
quickly becomes unmanageable. Obviously, nothing like a tightly
controlled nightly build cannot detect... The trick is to make sure the
appserver build can resolve to use _the_ approved version of the binary.
Above said, if we really can get away from having to support so many
different packaging built on top of glassfish (is your glass half empty
or half full?), one of the things we prototyped but scratched earlier is
to empty out appserv-rt.jar and use manifest class-path instead. The
manifest of appserv-rt.jar (similar to other composite jars) would point
to individual module jars. This would address both the individual build
problem and not breaking any existing scripts. The risk here is making
sure we are not sacraficing performance (for startup and deployment) and
not introducing classloading nightmares.
Thanks,
Q^2
Matthew L Daniel wrote:
>>We are starting the discussion on current GlassFish build framework,
>>issues faced around this and bring enhancements to the workspace. Please
>>share your experience on GlassFish build framework.
>>
>>
>
>As I have mentioned before, I think it's great that Glassfish started
>with Maven instead of an Ant or (worse) Makefile based build system.
>
>However, (also as I have mentioned before) I believe that the way
>Glassfish is using Maven is suboptimal. The boundary between Maven and
>Ant causes a lot of friction, in my experience. The build doesn't behave
>like a Maven build because it calls out to Ant almost immediately. The
>build doesn't behave like an Ant build because the invocation is buried
>under the Maven covers. That friction makes the build rough on both
>camps.
>
>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.
>
>I believe strongly that Maven2 (aka M2) should be involved in the
>discussions moving forward. Trying to "sort out" the M1 build is likely
>to result in more Jelly scripting, which is what M2 is trying to avoid.
>
>Also, I have formed a strong opinion about the need for the build to be
>SCM aware. I can think of two or three build breakages caused by an
>incomplete (read: missing files) commit.
>
>I have lots more to say about the SCM provider used by Glassfish, but
>I'll leave that for another discussion.
>
>Finally, I have heard the explanation of why the build system is the
>way it is, so I hope no one takes this as incendiary or anything other
>than one person's observation as a (more or less) outsider.
>
> -- /v\atthew
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
>