SpringSource has introduced the first milestone of Spring Migration Analyzer. This is a helper application that scans a JavaEE artifact and creates a summary report of APIs and classes that need extra attention if this application is to be migrated to Spring. This report can assist the migration evaluation since it can be used as an estimation tool for the effort needed to migrate.
Spring Migration Analyzer is offered as a command line utility that can be used on an OS with a JVM installation (it uses Java itself). It takes as input the binary deployment of an existing application (such as a war or ear file) and it creates as output (in a separate directory) an HTML report. The report contains a list of the JavaEE technologies detected, along with advice on effort required to migrate them to Spring/Tomcat. There is a general overview section but one can drill down to individual classes and see how they affect the migration effort (if they use a specific JavaEE API). The technologies in question are:
Here is a sample report: (click to enlarge)
/filters:no_upscale()/news/2012/12/spring-migration/en/resources/sma-report.png){kind=link}
Spring Migration Analyzer also detects additional features such as the type of EJBs (e.g. Session vs Entity), Spring libraries, vendor specific deployment descriptors, and even programmatic usage of transactions. For each technology detected there is a textual description on how/if it affects Spring Migration. The rest of the report contains the detailed structure of each class file found in the application, such as fields, methods, java imports, exceptions thrown etc.
Notice however that running the Analyzer with default options is not very helpful as the report contains a lot of false positives. The main reason for this is that because it deals with the binary artifact and not the source code, it does not distinguish between the actual code of the application and the code of external libraries. It would be ideal if the report excluded external libraries and only focused on the source code created by the developers (the same code that most other software reports deal with e.g. unit tests, code coverage, quality tools).
For example, a very simple application that uses Logback for logging is reported as if using JMS:
There is no JMS code in the source code, it is just that the logback binary also contains JMS imports since JMS is supported as a logging target. Therefore in order to get meaningful results you must also use the "exclude" command line switch to discard information of external libraries (for example the /WEB-INF/lib directory). Also the output directory cannot be the same as the input one.
So while in theory the command line switches of the utility are optional, in practice they are required. In summary at its present state Spring Migration Analyzer is a useful idea but needs some tweaking on how errors are reported to the user.
For more information see the documentation and current issues.The source code is hosted on GitHub.