From a physical point of view, a plugin is a jar file. From a logical point of view it is a set of classes that either extend or replace the framework layers; and while the former should be evident, the latter deserves an elaboration.
It has been mentioned here that layer jars are aware of the core but agnostic of one another. Consequently, any communication between them should go through the publicly exposed interfaces of the corresponding package contained in the core. The technique of hiding implementations behind interfaces is highly recommended in the world of container managed applications and reasonably so. It leaves a lot of room to the developer for alternate implementations (polymorphism), which along with some configuration magic at the container level, can be embedded in the framework seamlessly.
For example, a community member might feel that the implementation of the orm layer using native Hibernate is too restrictive and therefore, it should be replaced by an alternate implementation based on JPA or JDO. Likewise, another community member might feel that Spring Security - as a web security framework - is not the best choice among the ones offered and therefore, an alternate implementation is worthwhile.
Web4thejob not only enables but also encourages any initiative towards the expansion of the framework's intrinsic functionality.