Thread: [Php-java-bridge-users] =?utf-8?q?why_public_class_final_Response?= =?utf-8?q?_=3F?=

Hello,

I checked out from cvs repository and tried to compile.

But the process stopped at ClassicResponse.

It can not inherit from (now final) Response.

As php4 is not supported anymore, is ClassicResponse still needed?

Please, what could I do in order to compile?

Did I forget to configure something?

Regards.

Andre Felipe



-- 

"A Debian user never dies. Issues a last command:

shutdown -h now"

http://www.techforce.com.br

Hi Andre,

sorry, I forgot to remove that file from the repository. Thank you very much for looking into
this!

BTW: I think I have removed two files which were obsolete but are still referenced by the debian
packages.  I will check this this weekend and will give you a list of the changes.


What do you think about creating a zend extension from the java.so (or php_java.dll).
If it is possible to figure out the location of the php extension dir on debian, we
could change the java.ini from:

  extension=java.so

to

  zend_extension=/path/to/php/ext/dir/java.so

The advantage of the zend_extension is that we could build one extension for all php versions.
This generic DEB or RPM package will work on all future versions of PHP and, if the redhat or
debian people don't change the location of the extension dir, on all future debian and redhat
distributions.


Regards,
Jost Boekemeier



      Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail

Hello, Jost
Today I updated the ./debian directory with some improvements and
prunings.
Still needs further tests to announce it, but should compile and package
from a plain cvs checkout, as per README.debian .

Maybe the files you cited were removed from the packages by now.
Could you try to compile yourself in a Debian or maybe Ubuntu (virtual)
machine?

The Debian php extension directory is calculated dinamicaly at
compilation time by the line (today) 37:

	PHP_EXT_DIR := $(shell /usr/bin/php-config --extension-dir)

To edit the java.ini dinamicaly, some shell tricks should be performed,
and the postinst and postrm scripts could become really tricky.
Previous versions of Debian php had such nasty tricks to edit and
"unedit" ini files.
Today, the php packages are much more cleaner [0], [1].

As the php extension dir location is calculated at Debian package
compilation time, it will shurely compile for future versions.

Maybe I missed something, but in this scenario are there still
significant benefits of using zend_extension enough to justify dirty
tricks at packaging? 
I am trying to clean the packaging files and rules as I learn more [2].
The target is lintian zero errors and warnings [4] against Debian Policy
[3].

Best regards.
Andre Felipe Machado
http://www.techforce.com.br

[0] http://bugs.debian.org/388697
[1] http://bugs.debian.org/388698
[2] http://wiki.debian.org/PkgSplit
[3] http://www.debian.org/doc/debian-policy
[4] http://wiki.debian.org/WhyDebianForDevelopers

Hi Andre,

[please excuse the delay]

> Still needs further tests to announce it, but should compile and package
> from a plain cvs checkout, as per README.debian .

that's great. :)


> Maybe I missed something, but in this scenario are there still
> significant benefits of using zend_extension enough to justify dirty
> tricks at packaging? 

The only advantage the zend_extension offers is binary compatibility. 

We could as well leave everything as it is and add a note that users can load the
java.so as a zend_extension, if they want to.


Regards,
Jost Boekemeier





      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail