- We're using gobs of Spring XML and have taken it further to where all of our shared components are Spring Custom Schema Extensions.
- We use Log4j XML configuration with our custom appenders.
- We use Maven POM XML files for our builds
- We use Hibernate mapping XML files
- We use the web XML in WAR files
Annotations are a good start. While annotations may not be appropriate in every situation there are a lot of cases where they are a very good improvement over XML. All of the declarations in the web XML for WARs can now be discovered via annotations. Hibernate allows you to define your ORM mappings via annotations which is very nice that you don't have to go two places to see the fields and then the mapping. Spring has had an all annotation config for a while for most things.
My most recent experience has been with Spring Integration. While they allow you to use a DSL or annotations to develop the flow all of the examples use XML and the tests to my knowledge require XML. There is no examples of how to test without using XML and could not find anything on an internet search. I don't know why Spring even allows you to configure with XML anymore. Deprecate that junk and get rid of it. I'm not aware of anyone who actually externalizes the config files or loads different ones.
If you need something to make creation of a bean in Spring easier then write a Config class for it and encapsulate it in code rather in Spring XML Schema Extensions and Custom Parsers.
Maven is another problem. The philosophy of Maven is a little outdated. We don't use it's release plugin in our build pipeline. We're about to replace how it publishes artifacts. We have a bunch of custom plugins to get around the fact we're using XML instead of code. With new build tools like SBT (Scala) and Gradle (Groovy) code is now first class. If we need to delete or create a directory it's a couple lines of code instead of 40 lines of XML.
Log4j (Especially 2.x since we can have async appenders) is good but the XML should go. I'm not sure of anyone who externalizes the configuration and if they do it never changes once in production. Log4j is easy to configure. I don't know why everyone is afraid to configure Log4j in code. In Scala it'd be a Logging trait with a companion object for configuration. The way it is now in our projects we have XML with deprecated classes being used. It would be much easier to catch these sort of things with just code.
Going beyond XML being an outdated practice there are better alternatives for Scala in terms of embedded containers, object relational maps, automated acceptance tests, dependency injection, etc...