For earlier versions of both the frameworks book authors were saying that if we keep configuration in xml files then it will be easier to maintain (due to decoupling) and just by changing the xml file we can re-configure the application.
Back then annotations didn't exist. People hated the XML files, and Java got a horrible reputation because of them. Heck, there was a widely used tool (XDoclet) that generated XML config files from special JavaDoc comments, because maintaining them manually was such a pain!
When annotations were introduced in Java 5, everyone quickly realized that they were for most purposes much, much more maintainable than keeping things that configure intimate details of an application (like service dependencies or DB mappings) in a separate XML files. Realistically, most of the "configuration" is really code as far as changes are concerned, i.e. changes will be made as the application is developed (not while it's deployed) and usually together with changes in the code.
If we use annotations in our project and in future we want to re-configure application then again we have to compile and build the project.
Why is that a problem? Is you build process that horrible? Maybe you should work on that then. But note that both Spring and Hibernate still allow you to use XML configuration, even in combination with annotations. You can even override existing annotations from an XML config file.
So why these annotations were introduced in these frameworks? From my point of view annotations make the apps dependent on certain framework. Isn't it true?
The app depends on the framework anyway, otherwise you wouldn't need it. So why pretend otherwise? Besides, many of the annotations are now official Java standards (such as JPA and CDI) and supported by multiple different frameworks.