In a recent post to his site Herberto Graca shares some of his thoughts around packaging and namespacing and how it relates to the overall architecture of your application.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems: components, relationships between components [and] principles guiding the design and evolution of components and relationships.

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

The post then goes on to talk about "spaghetti" architecture, what makes for a more maintainable codebase and how this impacts the overall structure. He shares a few of the "packaging principles" previously defined by Robert C. Martin and the concept of "screaming architecture" (it should be very clear about how it's structured).

Pádraic Brady has followed up his last post on PEAR. This time he's covered the method to package and distribute source code using the PEAR installer.

All right then! You read the last blog entry advocating PEAR (or found it during the week ;-)) and you want to know all about packaging code so your users can install your library or application using the PEAR installer. A few things first:

1. You don't need to propose a package to PEAR to do this.
2. You don't need to create a PEAR "channel" although it's very much recommended (another future blog post no doubt).
3. You don't need a whole lot of effort.

Taking your source code, and generating a PEAR package is a relatively simple task.

He covers the process at lengths with easy to follow steps.

Pádraic Brady has followed up his last post on PEAR. This time he's covered the method to package and distribute source code using the PEAR installer.

All right then! You read the last blog entry advocating PEAR (or found it during the week ;-)) and you want to know all about packaging code so your users can install your library or application using the PEAR installer. A few things first:

1. You don't need to propose a package to PEAR to do this.
2. You don't need to create a PEAR "channel" although it's very much recommended (another future blog post no doubt).
3. You don't need a whole lot of effort.

Taking your source code, and generating a PEAR package is a relatively simple task.

He covers the process at lengths with easy to follow steps.