Initial classes for porting log4php to php5.

["Marco V." <ma...@apache.org>]

I've committed some core classes to create the php5 port of log4php.

The next steps (comments are welcome):

- Convert all the classes using the new php5 oo model.
- Create test cases using PEAR::PhpUnit2 
- Make some modifications to address new log4j features 
- Mark the log4php (the php4 trunk) as stable and release the 1.0 version.
- Discuss a new class namespace (log4php_XYZ, more PEAR compliant).

-Marco
 Log4php project maintainer

Re: Initial classes for porting log4php to php5.

["Marco V." <ma...@apache.org>]

----- Original Message -----
From: "Knut Urdalen" <kn...@telio.no>
To: "Log4PHP Dev" <lo...@logging.apache.org>
Sent: Tuesday, January 10, 2006 12:07 PM
Subject: Re: Initial classes for porting log4php to php5.


Hi Knut,

> I can help out with this if you create can give me a subversion account.

To have write access to log4php apache svn repository You should become a committer.
See http://www.apache.org/foundation/how-it-works.html#roles for details.
You can also contribute as a developer and provide patches, docs and new code.

> Personally I think we should leave class names as it is. I don't think
> we need to introduce a log4php_* prefix since the current classes is
> mostly named Logger*. Have anyone experienced naming conflicts with
> log4php? I think it's also important to stick to the names that is
> already being used in a number of applications and make the transition
> easier to the PHP 5 version.

Right, I think that the choice for the near future will be to let class names as is.
But we have to consider some factors:

1. Since php doesn't support class namespaces (how I hate this !!), coding using Logger* is not a good choice (especially for the
Logger class).
2. Some users asked me to "PEARize" log4php and for PEAR the log4php_* prefix is mandatory.

> Since we use PHPUnit2 for testing now it would be nice to use the unit
> test and code coverage reporting tools in Phing to drive the development
> process of log4php for PHP 5. Here's an example of how I'm using it with
> PRADO:
>
> 1) Unit Test Report: http://www.urdalen.com/prado/qa/report/
> 2) Code Coverage Report: http://www.urdalen.com/prado/qa/coverage/
>
> I can set this up if you want. Even nicer we could set up a nightly
> build or running these tests on svn commits so that we know that we
> don't break code in the subversion tree. What do you think?

Nice reports! I used ant to build source and docs for log4php but I think that Phing is better for a Php project.
With phing users can build source, docs, unit tests (PhpUnit for php4 and PhpUnit2 for php5) with code coverage.
Unfortunatly it's not so easy (but i'm not so sure) to setup nightly builds with apache infrastructure (especially as an incubated
project).

-Marco

Re: Initial classes for porting log4php to php5.

[Knut Urdalen <kn...@telio.no>]

Marco V. wrote:

>I've committed some core classes to create the php5 port of log4php.
>  
>
Nice :)

>The next steps (comments are welcome):
>
>- Convert all the classes using the new php5 oo model.
>- Create test cases using PEAR::PhpUnit2 
>  
>
I can help out with this if you create can give me a subversion account.

>- Make some modifications to address new log4j features 
>- Mark the log4php (the php4 trunk) as stable and release the 1.0 version.
>- Discuss a new class namespace (log4php_XYZ, more PEAR compliant).
>  
>
Personally I think we should leave class names as it is. I don't think 
we need to introduce a log4php_* prefix since the current classes is 
mostly named Logger*. Have anyone experienced naming conflicts with 
log4php? I think it's also important to stick to the names that is 
already being used in a number of applications and make the transition 
easier to the PHP 5 version.

Since we use PHPUnit2 for testing now it would be nice to use the unit 
test and code coverage reporting tools in Phing to drive the development 
process of log4php for PHP 5. Here's an example of how I'm using it with 
PRADO:

1) Unit Test Report: http://www.urdalen.com/prado/qa/report/
2) Code Coverage Report: http://www.urdalen.com/prado/qa/coverage/

I can set this up if you want. Even nicer we could set up a nightly 
build or running these tests on svn commits so that we know that we 
don't break code in the subversion tree. What do you think?

Best regards,
Knut Urdalen