Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-07 Thread Rene Engelhard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Christian Lohmaier wrote:
 On Tue, Mar 06, 2007 at 08:12:40PM +0100, Rony G. Flatscher wrote:
  
  it has been my understanding that the
  com.sun.star.comp.helper.Bootstrap class and its bootstrap() method
  are meant to allow bootstrapping OpenOffice in an easy manner/fashion on
  any operating system.
  
  As I have reported, on some Linux distributions that I have come to look
  at, the bootstrapping using  com.sun.star.comp.helper.Bootstrap does
  not work! 

Where is com.sun.star.helper.Bootstrap to be contained in?

 Maybe your distribution ships a crippled SDK.
 
 Check whether you have a valid unowinreg.dll
 
 see e.g.
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377531

This is available since 2.0.3-3. Since a long time that is.
Of course, the 1.1.3 in Debian stable doesn 't have it but I somehow
doubt he was using this.

In any case, you better should read the mail; he doesn't tell anything 
about Windows or accessing the library, but he just wants to run
the bootstrap mechanism on Linux. On which unowinreg.dll is completely
non-relevant.

  [...]
  So it seems to me that Rene tried hard to create an OOo distribution
  which adheres to both, the OOo and the Debian standards.
  However, it seems too, that using com.sun.star.comp.helper.Bootstrap's
  bootstrap does not work, as it is not able to find soffice!
  :-((
 
 Try with a vanilla build first, then you can shove it off to the paths

He did. That's why this discussion landed here again (after he asked me
what might be wrong)

 or something, or give the background details why you think it is the
 paths that are the problem.

Well, it *might* be the cause that OOo doesn't grok that classes/ is a
symlink. 

[EMAIL PROTECTED]:/usr/lib/openoffice/program$ ls -l classes
lrwxrwxrwx 1 root root 30 2007-03-04 22:33 classes - 
../../../share/java/openoffice

But a) the dir is there (although as a link) and b)

cd $(PKGDIR)-common/$(OODIR)/program  \
  for i in jvmfwk3rc setuprc unorc; do \
perl -pi -e \
  's,\$$ORIGIN/classes,file:///usr/share/java/openoffice$(VER),g' \
$$i; \
  done

the path in the config is changed. I just kept the dir for people/stuff who
expect classes/ there for compatibility reasons.

Rony, can you maybe try to make classes/ a real dir and copy all the stuff from
/usr/share/java/openoffice into there?
(Then I'll probably have to change this to actually be a real dir and make the 
jars in there
symlinks to /usr/share/java)

Any bootstrap mechanism experts here reading this? Ideas?

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7nI4+FmQsCSK63MRAituAJ9N1qb+Bb8/dmB1zN91O1HyzEWkIQCff+oB
d7vAOeYEz2j8nw1HM/5+jZY=
=PTOT
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-07 Thread Rene Engelhard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Rene Engelhard wrote:
 In any case, you better should read the mail; he doesn't tell anything 
 about Windows or accessing the library, but he just wants to run
 ^^^
 registry, obviously.

Regards,
 
Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7nNZ+FmQsCSK63MRAieDAJ9YfLjLwD6YbiBfmCVd5oCOxTb5NQCeMrO5
ANU1xfgusijdkAzOX2Qyg80=
=oyHR
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-07 Thread Stephan Bergmann

Rene Engelhard wrote:

Well, it *might* be the cause that OOo doesn't grok that classes/ is a
symlink. 


Yes, a symlink does not work here.  Much OOo Java code (residing in jar 
files in program/classes) needs to find other OOo files (native 
libraries etc.) and does so using NativeLibraryLoader 
(jurt/com/sun/star/lib/util/NativeLibraryLoader.java:1.9). 
NativeLibraryLoader effectively goes up the directory hierarchy one 
level from program/classes to program to locate those files.  That of 
course breaks if program/classes is a symlink to somewhere else.


Much OOo code (Java and C++) is working in ways that will break if the 
OOo installation structure is changed.  This is often problematic, and 
should overall be changed I think.  However, it also implies that 
whoever now fiddles with the OOo installation structure causes pain, not 
only to those poor souls that happen to use the deviating installation, 
but also to all community members who help to sort out the mess.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-07 Thread Rene Engelhard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Stephan Bergmann wrote:
 Rene Engelhard wrote:
 Well, it *might* be the cause that OOo doesn't grok that classes/ is a
 symlink. 
 
 Yes, a symlink does not work here.  Much OOo Java code (residing in jar 
 files in program/classes) needs to find other OOo files (native 
 libraries etc.) and does so using NativeLibraryLoader 
 (jurt/com/sun/star/lib/util/NativeLibraryLoader.java:1.9). 
 NativeLibraryLoader effectively goes up the directory hierarchy one 
 level from program/classes to program to locate those files.  That of 
 course breaks if program/classes is a symlink to somewhere else.

OK, as I feared. That also might explain some other problem I once had.

But to get sure, if I have classes/ as a normal dir and the jars/.class
files in there as symlinks to /usr/share/java/openoffice, that will
work, won't it?

 Much OOo code (Java and C++) is working in ways that will break if the 
 OOo installation structure is changed.  This is often problematic, and 
 should overall be changed I think.  However, it also implies that 

Indeed. Especially since I *do* spefify the path without the link
in the config..

Rony, please file a important bug for this referencing this thread
(URL best).

I'll fix it for the 2.2.0 packages.
I'd like to fix it also for the 2.0.4 packages for etch but I'd bet that
this change won't be approved now that late in the freeze, but I'll
try...

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7nxL+FmQsCSK63MRAh2aAJ9raRaBKRyZvWFaQb6FzW3wyOznCgCeJmeT
rkV2WP8dWL3oluroJSEhiQg=
=M4w3
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-07 Thread Stephan Bergmann

Rene Engelhard wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Stephan Bergmann wrote:

Rene Engelhard wrote:

Well, it *might* be the cause that OOo doesn't grok that classes/ is a
symlink. 
Yes, a symlink does not work here.  Much OOo Java code (residing in jar 
files in program/classes) needs to find other OOo files (native 
libraries etc.) and does so using NativeLibraryLoader 
(jurt/com/sun/star/lib/util/NativeLibraryLoader.java:1.9). 
NativeLibraryLoader effectively goes up the directory hierarchy one 
level from program/classes to program to locate those files.  That of 
course breaks if program/classes is a symlink to somewhere else.


OK, as I feared. That also might explain some other problem I once had.

But to get sure, if I have classes/ as a normal dir and the jars/.class
files in there as symlinks to /usr/share/java/openoffice, that will
work, won't it?


Probably.  Confer the hack magic of the getResource method at 
jurt/com/sun/star/lib/util/NativeLibraryLoader.java:1.9 l. 78--128.


-Stephan

[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-06 Thread Rony G. Flatscher
Hi there,

it has been my understanding that the
com.sun.star.comp.helper.Bootstrap class and its bootstrap() method
are meant to allow bootstrapping OpenOffice in an easy manner/fashion on
any operating system.

As I have reported, on some Linux distributions that I have come to look
at, the bootstrapping using  com.sun.star.comp.helper.Bootstrap does
not work! In the e-mails discussions in this group the reason was seen
in a directory structure that would not structured the way that OOo (the
helper class?) would expect it to be and hence would not be able to find
the necessary pieces to get OOo started up. As being able to start OOo
easily from the commandline *is* very important for many reasons it
would be therefore very important to be sure that the helper class (OOo
itself?) can successfully work on all distributions and succesfully
start-up from any configuration. Especially, if these distributions do
re-package OOo in a standardized way it seems, which has become state of
the art on those distributions!

---

In the meantime I was able to get in contact with Rene Engelhard, who
has been packaging OOo for Debian according to the documented OOo rules,
but in the process has been able to follow the standardized Linux
installation rules. This is (with his permission) what he wrote:

And this directory structure *IS* intact. we have ooodir/program where
all libs are and we have oodir/program/classes (which indeed get
changed, though as it's a symlink to a sane location following the
standard. But the path is changed in the OOo configuration, too to not
look in classes/ but in /usr/share/java/openoffice).

I even bit into the bullet and added /usr/bin/soffice which apparently is
needed for making the bootstrap thing work..


So it seems to me that Rene tried hard to create an OOo distribution
which adheres to both, the OOo and the Debian standards.
However, it seems too, that using com.sun.star.comp.helper.Bootstrap's
bootstrap does not work, as it is not able to find soffice!
:-((

---

Being stuck right now, I would request some suggestions/help on how to
proceed from here in order to make sure that the helper class is truly
able to startup OOo on any OOo installation that adheres to the
installation rules (which seems to be the case with the Debian package).

It would be quite awkward, if the only resolution at hand would be to
advise people to rip off an OOo installation which adheres to its
platform standards, and install the single-tree'd version that can be
downloaded from OOo's home, as this would imply that in reality there
was no freedom to adapt the OOo installation tree according to the rules
of the host system.

Thankful for any ideas/hints/help!

---rony




[dev] An example program that should work on all platforms from the commandline ... (Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-06 Thread Rony G. Flatscher
Hi there,

the following example program runs on many installations/platforms.

However, it *should* run flawlessly on *any* OOo installation:

 cut here (CreateTextDocument.java))

import com.sun.star.beans.PropertyValue;
import com.sun.star.comp.helper.Bootstrap;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.frame.XDesktop;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.text.XText;
import com.sun.star.text.XTextDocument;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;

class CreateTextDocument {
   public static void main (String args[]) {
  try {
 XComponentContext xContext=Bootstrap.bootstrap();  // bootstrap UNO
 XMultiComponentFactory xMCF=xContext.getServiceManager();
 if (xMCF != null) {
   Object
oDesktop=xMCF.createInstanceWithContext(com.sun.star.frame.Desktop,
xContext);
   XDesktop xDesktop=(XDesktop)
UnoRuntime.queryInterface(XDesktop.class, oDesktop);

   XComponentLoader xComponentLoader=(XComponentLoader)
   UnoRuntime.queryInterface(XComponentLoader.class, xDesktop);

   String url=private:factory/swriter;// define a
text document
   PropertyValue noProps[]=new PropertyValue[0];// no properties
   XComponent
xWriterComponent=xComponentLoader.loadComponentFromURL(
url, _blank, 0,
noProps);

// Fortsetzung nächste Seite ...
// ... Fortsetzung von vorheriger Seite

   XTextDocument xTextDocument=(XTextDocument)
   UnoRuntime.queryInterface(XTextDocument.class,
xWriterComponent);

   XText xText=xTextDocument.getText();
   xText.setString(Hallo Chemnitz, hier spricht Java!);
}
  }
  catch( Exception e) {
 e.printStackTrace(System.err);
 System.exit(1);
  }
  System.exit(0);
   }
}
 cut here 

Setup the environment such that CLASSPATH points to the following OOo
jars (wherever they are installed on the target system): jurt.jar,
unoil.jar, ridl.jar, and juh.jar (sandbox.jar is not needed anymore,
starting with OOo v2.0).

Then compile the program with the Java compiler (javac
CreateTextDocument.java) and run the compiled class with java
CreateTextDocument.

Regards,

---rony



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] Seeking help/ideas on making com.sun.star.comp.helper.Bootstrap work on all (Linux) distributions ...

2007-03-06 Thread Christian Lohmaier
Hi Rony,

On Tue, Mar 06, 2007 at 08:12:40PM +0100, Rony G. Flatscher wrote:
 
 it has been my understanding that the
 com.sun.star.comp.helper.Bootstrap class and its bootstrap() method
 are meant to allow bootstrapping OpenOffice in an easy manner/fashion on
 any operating system.
 
 As I have reported, on some Linux distributions that I have come to look
 at, the bootstrapping using  com.sun.star.comp.helper.Bootstrap does
 not work! 

Maybe your distribution ships a crippled SDK.

Check whether you have a valid unowinreg.dll

see e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377531

 
 In the meantime I was able to get in contact with Rene Engelhard, who
 has been packaging OOo for Debian according to the documented OOo rules,
 but in the process has been able to follow the standardized Linux
 installation rules.

The way vanilla OOo installs by default is perfectly within the
standards as wel...

 [...]
 So it seems to me that Rene tried hard to create an OOo distribution
 which adheres to both, the OOo and the Debian standards.
 However, it seems too, that using com.sun.star.comp.helper.Bootstrap's
 bootstrap does not work, as it is not able to find soffice!
 :-((

Try with a vanilla build first, then you can shove it off to the paths
or something, or give the background details why you think it is the
paths that are the problem.

ciao
Christian
-- 
NP: nichts

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]