Ok, fluorine as it stands is good enough for every package in the Tomcat stack with the possible exception of Tomcat itself, so I'm going to start fluorinating the Naoko packages. The advantages of this will be: * Instead of being defined in x-thousand lines of Makefile.am and configure.in, each package is defined in x-tens-of-lines of fluorine.xml. For example: Package Complexity Makefile.am + fluorine.xml (relative) configure.in (lines) (lines) commons-logging dead simple 189 19 jakarta-ant moderatly complex 2143 75 (approx) This simplicity makes things like upgrading to new versions, rearranging jarfile contents, etc, a breeze. * It _should_ fix every builddir != srcdir bug (and I found loads of them whilst writing it), every stupid relative path and broken sed bug, and every single bug where jarfiles and solibs have inconsistent contents. * Header generation is much more efficient, and jarfile contents are defined exactly (previously they were somewhat haphazard). Fluorine itself is a fairly small (<1000 lines) and straightforward piece of code and it should be fairly easy to understand and extend if necessary. Gary [ gbenson@redhat.com ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
tor 2003-11-20 klockan 16.42 skrev Gary Benson:
> Ok, fluorine as it stands is good enough for every package in the
> Tomcat stack with the possible exception of Tomcat itself, so I'm
> going to start fluorinating the Naoko packages. The advantages of
> this will be:
Is this software available somwhere for us mere mortals to look at?
/noa
Daniel Resare wrote: > tor 2003-11-20 klockan 16.42 skrev Gary Benson: > > Ok, fluorine as it stands is good enough for every package in the > > Tomcat stack with the possible exception of Tomcat itself, so I'm > > going to start fluorinating the Naoko packages. The advantages of > > this will be: > > Is this software available somwhere for us mere mortals to look at? http://sources.redhat.com/cgi-bin/cvsweb.cgi/rhug/fluorine/?cvsroot=rhug Gary
On Thu, 2003-11-20 at 07:42, Gary Benson wrote:
> * It _should_ fix every builddir != srcdir bug (and I found loads of
> them whilst writing it), every stupid relative path and broken sed
> bug, and every single bug where jarfiles and solibs have
> inconsistent contents.
One thing I noticed is that it only puts the srcdirs for packages it
depends on in the classpath. Better to put the buildirs for
dependencies, since then we'll pick up class files and compilation will
be much faster. Does this sound like an OK change?
In addition to this, it might also be better to build classfiles prior
to compiling the .java source for the same reason. I believe the
packages all built classfiles prior to fluorination. What do you think?
(BTW - I'm embarrassed to say that this is the first real look I've had
at fluorine - pretty cool!)
Thanks,
AG
--
Anthony Green <green@redhat.com>
Red Hat, Inc.