A POJO is a plain old Java object. Everyone talks POJOs these days. They are easy to compose and unit test. They are free of coupling to specific infrastructure details. So you can take your POJO to another infrastructure. For example, from JavaEE to Spring or OSGi. I like them and I think it is the right way to do things.
However, people are also fascinated with annotations now. Things like Guice and EJB3 and Glassfish all want you to annotate your POJO. But once you do that, your POJO ceases to be plain. While the non-annotation part of your code is still the same, the annotations in your code mean that your source now has coupling to specific infrastructure details and it is wrong to call is a POJO anymore. You can't compile your code without the proper support for those annotations. If you want to deploy your code in another infrastructure that uses annotations to describe the infrastructure details, you have to add more annotations to your source.
While I see the interest in putting the infrastructure information in the source near where it is used. We need to be honest. Your code is not a POJO anymore. It is now an AJO: an annotated Java object.