If Java dependencies on Openoffice.org can be adjusted, that should be done
first before being considered for the Live CD. Mono afaik isn't installed by
default on the Fedora 9 live cd. Reassigning

"file->wizards" is the first toplevel thing that requires java to function.

Though indeed it might be possible to hack OOo to split out the scripting
framework out of core into another rpm and hack things (in some currently
unconfigurable way) so that the requirements on the "odd" things like bsh could
be moved to their own mad little world to shrink requirements.

But the whole exercise is probably doomed unless regioned or zoned cds were
acceptable as OOo is translated too thoroughly into too many languages to fit
all of them onto a single cd, which is fedora policy I think. Most other distro
just whack the english version of OOo and a handful or other major languages
onto their livecds so they can fit it in.

yes, no mono in liveCD, that's a good point for fedora's liveCD

and yes, scripting in OOO needs java (and it can also be done in python too)
but none of those (Python nor Java nor VB) is important for opening/writing
.odt, .rtf, or .doc files,
more over the replacement in the fedora's liveCD like abiword don't support that
much of scripting, so yes, I'll be happy to drop wizards, scripting, mail merge,
forms, ..etc. if they are moved into ooo-core-jars and we put in comps.xml
ooo-core-jars as default to yes
so those features will be present in ooo in DVD and missing in LiveCD which is
normal

regarding bsh, I successfully move it out from core, to ooo-base and ooo-*filter

regarding i18n of openoffice, could you please give me a link to the policy
anyway, yes only English is included in other distro's liveCD (and this is
reasonable) and it's better than office at all
and local people can get the .ks file and build their own local ooo liveCD
maybe fedora policy don't allow making such liveCD, but it does not forbid local
teams here and there to build local ooo-enabled spins

my question now,
if I moved /usr/lib/openoffice.org/program/classes/*.jar
to some ooo-core-jars
do you think ooo-core will drain libgcj for some .so files like libjawt*
libjvmfwk* ..etc.

I did this RPM black magic 
rpm -ql openoffice.org-core | egrep '\.so(\.|$)' | xargs ldd > out.txt
egrep '(|$|jvm|jawt|gcj)' out.txt | less

and I found the following .so files that their name suggests that they should be
moved to the ooo-core-jars (or whatever we are going to call it, please suggest
a name)

basprov680li.uno.so, development680li.uno.so, developmentgui680li.uno.so,
dlgprov680li.uno.so, fpicker.uno.so, fps_gnome.uno.so, fps_office.uno.so
javaloader.uno.so, javavm.uno.so

so as we don't want scripting let's move all *.unu.so

but the output of that command suggests many non-uno .so files that depends on
/usr/lib/openoffice.orrg/program/libjvmfwk.so.3
like libhypthen680li.so

rpm -ql openoffice.org-core | grep -v uno | egrep '\.so(\.|$)' | xargs ldd >
non-uno-out.txt
egrep '(|$|jvm|jawt|gcj)' non-uno-out.txt | less

what is the next step!

You can move java stuff out of the core rpm, but you'll be left with a
file->wizards that doesn't work and other dangling UI entries that point to java
based functionality unless you also do some work to tweak the config to remove
the entries from the OOo menus unless the appropriate rpms are installed. e.g.
see the pyuno rpm or emailmerge where there are config "fragments" like...
/usr/lib/openoffice.org/share/registry/modules/org/openoffice/Office/Scripting/Scripting-python.xcu
and
/usr/lib/openoffice.org/share/registry/modules/org/openoffice/Office/Writer/Writer-javamail.xcu
which control enabling and displaying the matching UI bits that control the
optional features in those rpms

> You can move java stuff out of the core rpm, but you'll be left with a
file->wizards that doesn't work and other dangling UI entries that point to java
based functionality

this is fine if it does not crash writer I mean, if the user gets "unable to so
and so because of so and so, please install so and so"

I don't want to remove them, I want to move them!
I want this functionality to be back when the user installs the needed rpm

I think this should be given more priority in Fedora,
LiveCD user should be able to get full functionality without replacing the
entire ooo, just installing the missing parts

Of course, it would me much better if all those functionalities are implemented
in python! but this is not our job here at fedora.

I'll try my best, but rebuilding OOO needs an entire night and 20GB of free
space, this limits the number of trials I'll do.

Its not fine to have broken menu entries, if the functionality they access isn't
there then, as you say it needs to say "install X", or the menu shouldn't be
there in the first place. And that should be doable in most cases with the xml
UI config system where the menus can be added to by sub-rpms.

Created attachment 310914 [details]
spec that fails to drop java from ooo-core

I tried to to build ooo from a custom spec file based on the one from f9
I moved all jar and .class files from -core to core-jars

but the -core still depends on libjawt.so

$ rpm -R -qp openoffice.org-core-2.4.1-17.5.oj1.i386.rpm | grep jawt
libjawt.so

this will drain libgcj
there must be a binary somewhere that required it
I tried rpm -ql then pipe that to grep then to xargs ldd
but no .so file need it, it could be a binary
I'll inspect that from my side but please take a look on my .spec file
and try to kick java out of -core, then we will go through .xcu files

some of the help files are nothing but a renamed .zip files into a .jar file like
/usr/lib/openoffice.org/help/en/schart.jar

libofficebean.so has the direct ld requires on libjawt.so|

I have just discovered that!

I'll try to move that away and see, I hope there is no hidden surprises.

Created attachment 311050 [details]
spec file having no java dependency on core

before using this spec file, I've changed the vendor to avoid trademark
violation, please but the vendor back to redhat