[kaffe] Build system for kjc / external jars + Jetty/JSP success

[Dalibor Topic]

hi Jim,

--- Jim Pick <jim@kaffe.org> wrote:

> I played around a bit on the weekend with Jetty, and trying to get it
> working on top of Kaffe with JSPs.  Out of the box, Jetty works with the
> latest CVS, but not the JSPs.  I really wanted to get JSPs working with
> something that supports the Servlet 2.3 spec, since I've been playing
> around with doing some really cool stuff using JSTL.  I want to switch
> Kaffe.org over to something that runs on Kaffe.  :-)

yeah, sounds quite cool to me ;) Having kaffe.org run on kaffe would be a nice
way to show that the project is alive and kicking.

> It took me all weekend to figure out what was going wrong, and to come
> up with a fix.  Jetty uses Jasper (from Tomcat) to generate the Java
> code, which then gets turned into a class file using the "javac" task
> from ant.jar (using -Dbuild.compiler=kjc).  It turns out that, by
> default, kjc likes to stick the compiled .class files in the current
> directory, instead of in the same directory as the source .java file, as
> javac does.
>
> I cooked up a crude patch against kjc which seems to work. 
> Unfortunately, it's a big mangled since I rearranged the kjc source dirs
> so I could get it to fit into Eclipse (which expects the sources to be
> laid out javac-style).  I need to clean it up.

When it's finished, please send it over to Martin Lackner and Thomas Graf from
kjc to get it in their next release. Do you have any information if/when there
is going to be a new release of kjc?

> What we're currently lacking is a build system for rebuilding kjc.jar.
> 
> I'd like to propose a new top level module in CVS where we can check in
> a build system for generating "external jars" that get shipped along
> with Kaffe.  Kjc is on such "external jar".
>
> For documentation purposes, I'd also like to ship some additional jars,
> eg. an XSLT engine, docbook stylesheets, a cut-down version of ant (with
> needed Kaffe hacks), etc.  There might be additional jars we might want
> to pack into the shipping tarball.

I'd propose adding BCEL, jasmin (needed for some regression tests in JanosVM,
and eventually in kaffe) and DNSjava (optional pure java DNS implementation).

> I'm proposing we call it "kaffe-external-jars".  Having only spent 30
> seconds thinking of the right name for it, I'm open to a less wordy name
> for the module.  I'd like to avoid checking in binaries.  Instead, we
> could do something more along the lines of a BSD-style "ports" system,
> where we'd have scripts that would download the "pristine" source
> tarballs, and apply patches against them, and build our jar files, which
> could then be checked into the main Kaffe tree, as needed.
> 
> What do people think of that?  I'm open to alternate ideas.

I like the idea. I think we should somewhere, somehow, be able to build the
java tools we rely (or will rely on) for creating kaffe using kaffe. You way of
doing it sounds quite cool, and I liked the approach you used with the libtool
patches.

I'm not sure how it will affect kaffe's status in debian though. Didn't they
have that weird policy that if we used ant anywhere, kaffe would have to be
removed from debian-free? Or am I just misremembering last year's big licensing
thread?

cheers,
dalibor topic

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com