Packages should be designed so that a change in the contents should not cause a ripple effect on other packages. Of course some utility packages will always have this problem, but most packages should be self-contained and give a public view of stability to other packages, at least to packages other than its children.
Tip: Have a package-wide exception, and subclasses thereof. If all classes inside a package called weather throw only a WeatherException (or a subclass of WeatherException), you will rarely need to change exception handlers for code that depends on the package.
and
Tip: Don't pass things unrelated objects like HttpServletRequest into other packages except to packages that deal directly with requests or web related activity. For example, you would not pass HttpServletRequest into a WeatherService which is only interested in weather. Extract the variables you need from the request and pass them in.
So packages should depend only on packages and JAR files that change less frequently than themselves.
For example, java files in the package com.xyz.timesheets.web.controller.* can import the common library class com.xyz.common.config.DynamicConfigurationLoader.java which hardly ever changes.
But if DynamicConfigurationLoader.java imports classes from packages that change regularly or are not stable, perhaps the package structure needs revisiting.
Poorly designed Exceptions are often the cause of dependency leakage. Developers will often reuse exception types from unrelated packages to save time, and this unnecessarily bleeds dependencies from one package to another. See the [exception.package] rule for more information on this.
