3. which is our motivation?
DRYDon’t repeat yourself.
4. What are coding conventions?
“coding conventions are a set of guidelines for a specific programming
language that recommend programming style, practices and methods for
each aspect of a piece program written in this language.” wikipedia
5. convention types
• Formatting rules: headers, indentation, documentation, code style..
• Naming rules: labeling rules for methods, classes..
• Best practices: software patterns, common bugs resolution..
8. “it takes a while to create nothing”
Ron Jeffries
9. our goals
• automatizing the resolution of problems detected by code quality tools
(i.e PMD, , sonar, findbugs).
• automatizing the development and repetitive tasks i.e: creating basic
CRUD services for the entire model.
10. walkmod is open!
• open source: feel free to suggest changes!
• free for everybody: tell it to your boss!
• extensible by plugins do it yourself and share them! DIY+S
Introduction
13. >_ man walkmod
• >_ walkmod apply modifies the source code according a set of coding
conventions
• >_ walkmod check specifies which source files do not follow a set of
coding conventions
how it works
14. conventions driven by transformations
how it works
• Coding conventions are applied with blocks of transformations for each
source file.
•Transformations may update the same sources or creating/updating
another ones.
15. overview
• reader: reads the sources. i.e retrieves all files from a directory
recursively.
• walker: executes a chain of transformations for each source.
• writer: writes the sources. i.e using the eclipse formatter.
how it works
17. reader
• Reads the sources. By default, reads the folder src/main/java.
• Works with multiple include/exclude rules.
• Creates a resource object, whose content is iterated from the walker.
how it works
18. walker
• Executes a chain of transformations for each object allocated in a
resource. i.e all java source files of an specific folder.
• merges the output produced by transformations with existent
resources.
• analyzes and reports which changes have been produced by the chain
of transformations in each object.
• invokes the writer with the final (and merged) output if there is any
change.
how it works
19. writer
• writes each object allocated in a resource. i.e all java source files of a
specific folder.
• Has include/exclude rules.
• There are useful writer implementations, such as the storage of the
contents of a toString() object method or the eclipse formatter.
how it works
23. public class HelloVisitor extends VoidVisitor<VisitorContext>{
...
@Overwrite
public void visit(MethodDeclaration md, VisitorContext ctx){
//TODO
}
@Overwrite
public void visit(FieldDeclaration fd, VisitorContext ctx){
//TODO
}
...
}
transformations
24. why visitors?
• Visitor design pattern is a way of separating an algorithm from an
object structure on which it operates.
• Straight-forward way to design code transformations in java.
• Visitors can just be shared by means of walkmod plugins.
transformations
27. scripts
• Scripts allow the design of inline transformations.
• Scripts should be used to apply simple modifications in source files.
• Support for multiple languages.Those which implement the standard
Java scripting interface. i.e. groovy, javascript, python..
transformations
30. templates
transformations
• What You See Is What You Get (WYSIWYG): Simplest way to dynamic
content to follow a given convention.
• groovy is the default template engine, but can be customized.
31. remember
transformations
• Visitors: a straight-forward way to design code transformations in java.
• scripts: to design inline transformations without creating a java library.
• templates: WYSIWYG transformations.
35. query language
• The default query language is gPath (groovy), but you can change it for
your favorite language.
• Common used large query expressions can be referenced from Alias.
“TypeDeclaration.metaClass.getMethods = { -> delegate.members.findAll({it instanceof MethodDeclaration}); }”
query engine
36. queries from templates
Using the query object: ${query.resolve(“expr”)}.
query engine
import org.apache.log4j.Logger;
public class ${query.resolve("type.name")}{
public static Logger log = Logger.getLogger(${query.resolve("type.name")}.class);
}
template to add Loggers
37. queries from scripts
accessing through a binding called query
query engine
..
for( type in node.types) {
def result = query.resolve(type, “methods”);
...
}
...
groovy script querying the type methods
38. queries from visitors
Implementing QueryEngineAware or extendingVisitorSupport.
query engine
public class MyVisitor extends VisitorSupport{
@Overwrite
public void visit(TypeDeclaration td, VisitorContext ctx){
Object result = query(
td, //context
“methods.find({it.name.equals(“foo”)})” //expr
);
}
}
visitor code with a gpath query
40. why a merge engine?
• Developer changes are respected (e.g. adding a new method).
• Simplify transformations. Otherwise, transformations would check
many conditions to avoid repeating code or overwriting it.
merge engine
46. semantic merge
• Code is merged according to the meaning of its elements instead of
simply merging text.
• Each node type has an specific merge policy.
merge engine
47. named nodes | anonymous nodes
• named nodes: those nodes identifiable inside an AST.
e.g. methods or fields of a given type
• anonymous nodes: those non-identifiable.
e.g. statements of a method
merge engine
48. merging named nodes
• append policy: only adds non existing nodes generated by a
transformation.
• overwrite policy: always replaces existing nodes by the generated
ones.
merge engine
49. merging anonymous nodes
• assign policy replaces the whole original list of nodes by generated
nodes.
• unmodify policy maintains the original list of nodes.
• addall policy appends the whole list of generated nodes into the
original list.
merge engine
53. how to extend walkmod?
• Creating new java libraries and deploying them into a maven
repository (public or private) with the name walkmod-xxx-plugin.
• All walkmod extensions need a plugin descriptor of their components
in the META-INF/walkmod directory inside the jar library.
plugins
54. plugins backend
• Walkmod embeds apache ivy to download plugins from maven
repositories in runtime.
• Custom repositories are in ${walkmod-home}/conf/ivysettings.xml
• All plugin jars and their dependencies are files loaded dynamically into
a new classloader.
plugins
56. next steps
• + plugins: Create and publish new plugins (e.g. naming rules or
support for other programming languages).
• - less configuration: reutilization by inheritance / include rules of the
XML elements.
• saas: publish online services for running walkmod and all its plugins
(also private).
roadmap
