On Fri, 2005-09-16 at 17:04 -0400, David Walluck wrote:
Anthony Green has written gcjlib, but it is cumbersome to have to
every single build.xml, which is why a script that does the same thing
is generally preferred. But for upstream projects, it might make sense
for them to adopt gcjlib.
It's cumbersome to have to patch build.xml files.
It's cumbersome to write and maintain spec files for hundreds of
applications, especially if there ended up having to be one 'generic'
JPP one, and one FC specific one.
Upstream Java developers shouldn't have to worry about RPM spec files,
deb files, GCJ libs, Windows installers, BeOS thingamajigs, etc.
When I moved my Java project from Windows using Sun's tools, to Fedora
and GCJ, my Ant build.xml file Just Worked. That layer of insulation
meant I didnt' have to learn about GCJ command line options to compile
my code. This type of abstraction needs to be taken to the next level.
Ideally, everyone just writes platform independent Java code, and fills
out some platform agnostic thing to describe their application, it's
version, dependencies, etc - all in a declarative fashion. Everything
else from that point on through to end user deployment should be fully
automated by a mix of generic and platform specific tools. I think
Maven's project.xml is a good start to supply exactly that. There
should be tools/plugins/whatever, to turn a project.xml file into an RPM
suitable for Fedora, or a .deb for Debian, etc. And if project.xml
doesn't supply all the information needed to make this work, maybe we
should help fix that.
Instead of JPP creating spec files, they could write a project.xml file
for everything. Then as the mechanisms get worked out, you just upgrade
and maintain the tool chain. Constantly futzing around tweaking code in
hundreds of hand written spec files seems silly to me.