PackagePerLayer refers to the practice of grouping all objects related to one layer of an ''n''-tier application (see MultiTierArchitecture) in the same Java package.

----
''Would that be "at least one package per layer"?''

Yes. But you would probably have subpackages for that layer as opposed to having several packages at the same level as those for other layers (does that make sense?). I'm not as sure as I was a year ago that this is the best way to group classes.
----
Isn't there a problem if I depend on one of these sub-packages but not on the enclosing package?
i.e Imagine the 'layer-packages': alpha, beta and gamma. Each contains sub packages called one, two and three. These contain sub-packages called huey, dewey and louis. Now imagine a situation where a class in alpha.one.dewey depends on something in gamma.three.louis. Don't we end up with a nest of dependencies that are not as clear as the initial idea of PackagePerLayer suggests? I do this myself but I find that these kinds of situations with deep package hierarchies often occur.
----
PackagePerLayer is just another way of doing CodeOwnership. 'Or maybe not. In general, you still need to organize your code even if you apply a "no CodeOwnership" policy. In practice, though, the organization of the project closely follows the political organization of the team.'