walkmod-refactor-plugin

This is a walkmod plugin to support refactoring rules (mainly for migrations) in Java source files.

This plugin is specially useful when you need to upgrade a project dependency (java library), and in the new version, you have found that some methods have changed their names, arguments..; others become deprecated and some classes have been renamed, too. In this situation, you can spend a lot of time changing those parts of code that stop to compile or update automatically your code with this walkmod plugin :).

This walkmod plugins reads all your code expressions and rewrite them according the new API of the updraded library. These code expressions are rewriten according a set of refactoring rules.

Refactoring rules

This plugin supports two types of refactoring rules: class refactoring rules to rewrite those references of classes whose name has changed; and method refactoring rules to rewrite those method calls that have a different name or arguments.

Class refactoring rules

Class refactoring rules are renaming rules for Java classes. To specify class refactoring rules, you need to create a json file, with a simple json object, whose field names are the old names of Java classes, and their values the new class names.

For example, imagine you are using a Java library (Maven dependency), which contains a class called foo.Bar and you need to upgrade this library to the newest version, where the class foo.Bar has been renamed to foo.BarDAO. You need to specify this rule as follows:

{
  "foo.Bar": "foo.BarDAO"
}

Method refactoring rules

Method refactoring rules support three scenarios:

1. Method Renaming: For those methods that have changed their name. Example: foo.Bar:execute() => foo.Bar:run()

2. Argument Rules: For those methods that have changed their arguments (type, order o quantity). For this type of rules, you need to specify the whole class name and an alias for each argument (e.g foo.Bar:open(java.io.File file)). Then, you could use the alias in expressions if you can derive the new argument type of these methods (e.g foo.Bar:open(file.getPath())). The character separator between arguments is the ;.

3. Result Rules: for those methods that have changed their result type. There is a keyword called result to specify how the new method call must be transformed into a new expression to ensure the code follows the same workflow. For example: foo.Resource:isOpen() => foo.Resource:isClosed():!result

To specify method refactoring rules, you need to create a json file with a simple json oblect, with key-value pairs consisting of the original method declaration and the new one, as follows:

{
 "foo.Bar:execute()" : "foo.Bar:run()",
 "foo.Bar:open(java.io.File file)" : "foo.Bar:open(file.getPath())",
 "foo.Bar:open(java.io.File file; java.lang.Boolean append)" : "foo.Bar:open(file.getPath(); append)",
 "foo.Resource:isOpen()" : "foo.Resource:isClosed():!result"
}

Example

According the previous configurations, if we have the following Java code:

public void hello(File file){
	Bar bar = new Bar();
	bar.open(file);
	Resource res = bar.getResource();
	if(res.isOpen()){
		...
	}
	...
}

It is rewriten to this one:

public void hello(File file){
	BarDAO bar = new BarDAO();
	bar.open(file.getPath());
	Resource res = bar.getResource();
	if(!res.isClosed()){
		...
	}
	...
}

Usage

We recommend to use the last version of walkmod because it becomes easier to configure.

Walkmod >= 2.2.0

If your project is build with maven or gradle, you simply need to execute:

walkmod add -DrefactoringConfigFile="src/main/walkmod/refactor/refactoring-methods.json" refactor:methods

To refactor methods.

If you need to refactor java classes:

walkmod add -DrefactoringConfigFile="src/main/walkmod/refactor/refactoring-methods.json" refactor:classes

Previous versions

1. Add your project build tool (maven or gradle) ad a configuration provider into the `walkmod.xml.

2. Add the transformations org.walkmod:walkmod-refactor-plugin:methods and org.walkmod:walkmod-refactor-plugin:classes into your walkmod.xml and set your refactoring configurations.

<!DOCTYPE walkmod PUBLIC "-//WALKMOD//DTD"  "http://www.walkmod.com/dtd/walkmod-1.1.dtd" >
<walkmod>
  <conf-providers>
    <conf-provider type="maven"></conf-provider>
  </conf-providers>
  <chain name="main-chain">
    <transformation type="org.walkmod:walkmod-refactor-plugin:methods">
      <param name="refactoringConfigFile">src/main/walkmod/refactor/refactoring-methods.json</param>
    </transformation>
    <transformation type="org.walkmod:walkmod-refactor-plugin:classes">
      <param name="refactoringConfigFile">src/main/walkmod/refactor/refactoring-classes.json</param>
    </transformation>
  </chain>
</walkmod>

If you decide to store the refactor configurations in the same place than the example, you can avoid define these params.

1. Type and execute walkmod apply in your shell from your project directory.

2. Now, you can upgrade you maven dependency and check if the project compiles :)

Contributing

If you want to hack on this, fork it, improve it and send me a pull request.

To get started using it, just clone it and call mvn install.