OpenOffice and go-oo

Caolán McNamara caolanm at
Tue Oct 14 22:51:21 UTC 2008

On Tue, 2008-10-14 at 20:54 +0300, Muayyad AlSadi wrote:
> > a) what happens when you run file->wizards->letter ?
> > c) what happens when you use tools->xml filter settings-> and add a new
> > xslt transform and use "test xslts"
> >
> > Those examples need java to work, whether or vanilla.
> >
> regarding a, c in go-oo 2.4.x they just say "please install jre
> package" see attachement

There's no magic go-ooo pixie dust there, that's a vanilla dialog shown
when no jvm/java-infrastructure at all is found when trying to trigger
java-dependant functionality. The OOo of that screen-shot hasn't found a
jvm at all. If there *was* a jvm, the next stage would be to find out
that the next set of requirements is missing, at which point something
generally will fail silently. i.e. that dialog says "no java was found",
if there *was* a java but not e.g. lucene/saxon it will say nothing and
just not work. That's a miserable user experience, and people will in
their thousands get into that situation and not be able to get out it.

> and b,d they are not included in the livecd they are in a separated
> package, anyway who needs ooo-base in a livecd, fedora livecd don't
> ship any replacement ooo-base.

Sure, and dropping oobase from a LiveCD is reasonable, so the hsqldb
requires in F-10 is now just on oobase, rather than core. My point there
was that is no different from vanilla in needing java to work
correctly, and moving to gains you very little in terms of a
java-less OOo.

Not "Require:"ing the Java requirements for help and other always
presented dialogs and menus that are shown as available is to fudge the
reality that OOo truly does require those packages for Ooo to fulfil the
contract that the UI makes with the user. 

Taking "removing java from core dependencies" as the target, then the
right approach is the boring slow-fix stuff to e.g. rewrite the help
search to not require the java lucene stuff and to tweak the xsltfilter
stuff to be a standalone expert-style feature that only appears in the
menus when the xsltfilter package is installed and place the saxon
requires on that subpackage, and so on for other java functionality. 

Or not do any of that, and investigate further as to why exactly
removing or replacing java dependencies is the target, when I last
thought seriously about the area I felt the right thing to do was stop
swimming against the tide and boil out some concrete standalone feature
requires for gcj to be able to provide the functionality that was
missing at that stage to implement the java-needs of OOo, and our
fabulous java hackers simply implemented them. Your questions should be
what exactly are the size figures are for requiring the java
dependencies and where is that space getting used and why.

> I'm not asking to make the striped openoffice the default, I'm asking
> to make the default behaviour in comps to be full featured, but
> packages dependency should allow removal of java

I think this is the wrong approach. OOo will just end up getting
installed part-working an awful lot of the time and the OOo maintainer
of the day will have to deal with the resulting justified bile and

I'm no lover of java, and I've previously expended effort of making OOo
buildable without java for platforms that don't have a working java and
on replacing java functionality with native code in some time critial
build-paths, so I'm all in favour of what you want to achieve, but I
don't want to compromise to make it happen.


More information about the fedora-devel-list mailing list