[TYPO3-ect] Phing - Don't repeat yourself

[Elmar Hinz]

DRY,

<quote http://en.wikipedia.org/wiki/Don't_repeat_yourself>
Don't Repeat Yourself (DRY, also known as Once and Only Once or Single Point
of Truth (SPOT)) is a process philosophy aimed at reducing duplication,
particularly in computing. The philosophy emphasizes that information
should not be duplicated, because duplication increases the difficulty of
change, may decrease clarity, and leads to opportunities for inconsistency.
DRY is a core principle of Andy Hunt and Dave Thomas's book The Pragmatic
Programmer. </quote>

Before searching for a way to, apply Phing [1] to T3 extensions a tested it
in a little independent project (PHPUnit_CoolUI) [2], that I could
configure as I pleased. And it was indeed a pleasure. After having learned
and integrated Doxygen [3], Docutils [4] and Phing I was able to process a
full new release with one click. Editing, updating the source files,
INSTALL, README, TODO, FeatureRequests, ChangeLog, etc. with version and
path informations. Including a lot of this informations automatically into
the manual and finally packing it all to a tarball for release. 

DRY, this self-evident principle is not always that simple to reach and far
away from beeing systematically applidd within TYPO3. Just the opposit it's
hard to publish a clean extension, that respects all coding guidelines. 

Take the Changelog as example. There is a ChangeLog file in the extension.
The ChangeLog should be appended to the manual and also uploaded to TER.
It's similar for the TODO file. The current version should ideally be added
to all class files, that have been altered and nearly in every involved
file and document. 

Well, there are solutions. CVS [5] and SVN [6] can automatically update
version markers in the sourcode. API generator tools can apply version
informations to the generated API, that is configured in the configuration.
Document generators offer markup for automatic insertion of informations
like version string. All this can simplify the maintainance of software,
but you still have to manually adapt the configuration files of the
different tools to set the current properties.

Another step is needed, to autoupdate the differnt configuration files and
to run and controll the generators and tools efficiently. Nothing special,
no need to reinvent the wheel. Programming of compiled languages like C or
Java can't be done efficiantly without a tool for this. There are different
Makes [7] for C, C++ there is Ant [8] for Java. Certainly you could write
simple shell scripts to reach similar targets or use a scripting language
like PHP. 

PHP doesn't need to be compiled and the project management can be coded in
PHP directly. Reasons why tools like Ant havn't been available for PHP
early. However, a few years Phing is availble implementing conceptions of
Ant for PHP. 

Setting up a development environment with Phing sounds oversized for a
little freelancer developing a small TYPO3 extension. In the moment you
want to maintain a public open source product over multiple versions, with
user and admin documentation, with licences, maybe with a website, such an
environment becomes extremly handy. Not to speak of a bigger project team
with multiple persons. 

What system do you use? 
Should we set up such an environment for extension development?
What tools would you recommend to inclde?


[1] Phing: http://phing.info/docs/guide/current/
[2] PHPUnit_CoolUI: http://sourceforge.net/projects/cool/
[3] Doygen: http://www.stack.nl/~dimitri/doxygen/
[4] Docutils: http://docutils.sourceforge.net/
[5] CVS: http://www.nongnu.org/cvs/
[6] SVN: http://subversion.tigris.org/
[7] Make: http://www.gnu.org/software/make/manual/html_node/index.html
[8] Ant: http://ant.apache.org/manual/index.html