PHP project organisation

Question

Currently I just have a bunch of php files sitting in folders under source control. Logically I have a collection of related projects and a shared database.

• Project 1 is a web application interacting with a database.
• Project 2 is some background processes also interacting with the same database.
• Project 3 is a library including extended database connection objects and other utility functions.

Project 1 and 2 depend on the library code.

I want to split the projects into three separate repositories so they can be developed independently.

What is the best approach to organising the first two projects so they depend on the library but don't need their own copy of the library in their source tree?

Should I convert the library in to a PEAR package and have that package installed system wide. Or is it better that projects 1 and 2 are 'build / deployed' in some sense and include a copy of the library during that build step. This approach would imply the use of some kind of build management tool like Phing / PHP-Maven.

Answer 1

Keeping a copy of the code within the source tree is not a bad thing. It allows you to control when you go through the upgrade phases rather than have the system impose it on your application. It is quite a bad situation when you need to release your code and a library change occurs just before, forcing you to make last minute changes on software that had to go live.

If you are using subversion, you can use externals to include the library code into your application and lock it at a certain revision. Updating it is just about editing a property to change the version number and update the code.

Other version control tools can offer similar functionalities. Some projects like Symfony2 also include a script to manage dependencies, however they only support git.

Answer 2

Perhaps because I'm a maven user, I would prefer to declare project3 as a dependency of project1 and project2 and use maven as the build management tool and dependency resolver (among other things). The version problem pointed by @Louis-Philippe Huberdeau can be avoide using versions and declaring the dependencies to be version specific: i.e, for development projects can depend on project3-1.0-SNAPSHOT and for the release the dependency will become project3-1.0-RELEASE. This way the three projects can evolve independently. The versioning and deploying of the artifacts can be done by maven. Later, if you need it, you can use a CI server, like hudson or Travis CI.