|
As such I would expect additional goals (2 of them) for templating, e.g.
generate-[test-]sources mojos
They would presumably take a configuration that identified the templating engine, e.g.
<configuration>
<templates>
<template>
<source>src/templates/foo.java.hbs<source>
<engine>handlebars</engine>
<properties>
<package>com.mypackage.foo</package>
<title>blah blah</title>
</properties>
</template>
</templates>
</configuration>
Now as such, it would make sense when resolving the template, to not only pick up from the project but if that fails, fall back to the plugin's classpath (just as pmd:pmd and checkstyle:checkstyle do for their rulesets)
In such a case, this project info plugin would actually be either an engine that does not need a source, or a standard template using the default engine, iterating all properties and skipping a property called "package" to use that for the package name instead.
e.g. in handlebars you would probably have
package properties.package;
public final class ProjectInfo {
private ProjectInfo() {
}
private static final class ResourceHolder
{
private static final ProjectInfo INSTANCE = new ProjectInfo();
}
public static ProjectInfo instance()
{
return ResourceHolder.INSTANCE;
}
#each propertyEntries
public String get{{key}}() {
return "value";
}
/each
}
(yeah I know you'd probably want to use velocity for this one so you can handle escaping of special characters in the key and the value but you get the idea)
|
