Well I had a different idea...
The plan is to add support for templating engines to the
templating-maven-plugin.
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)
On 28 May 2013 09:13, Baptiste MATHUS <[email protected]> wrote:
> Yup, thanks for posting it here. Users need that there's not too many
> plugins doing the same or similar things imo.
> I've thought just a bit about it and was planning to answer. I don't know
> yet how this could be merged, but I think it should be somehow with
> templating-maven-plugin<http://mojo.codehaus.org/templating-maven-plugin/>
> .
>
> I'm a bit uneasy about generating Java class with *all* the props, since
> this can easily lead to kind of exposing too many things. And as the
> general programming rule says, it's easier to add than to remove things.
>
> Maybe the filter-[test-]sources mojo could be enriched (and maybe renamed)
> so that it can generate that default Java class under some package/name
> (with public static final attributes) ? This way people would have the
> default Java class with props if they want, and be back to custom classes
> or whatever if they prefer finer grained control?
>
> WDYT?
>
>
> 2013/5/28 Anders Hammar <[email protected]>
>
>> Wouter, thanks for posting your suggestion here!
>>
>> Do any of the other devs here have any input? Is this useful? Should it
>> be included in some other plugin or does it call for a separate plugin?
>> Maybe as a utility goal of the templating plugin?
>>
>> /Anders
>>
>>
>> On Thu, May 23, 2013 at 2:39 PM, Wouter <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> I have written a plugin and I was wondering if you think it's of any
>>> use, and if so, if it could be part of the Mojo project.
>>>
>>> The goal of the plugin is to make POM properties accessible from Java
>>> code. It generates a Java class with some constants whose values are
>>> defined in pom.xml. I call it the Project Info plugin. Example
>>> generated class:
>>>
>>> public class ProjectInfo
>>> {
>>> public static final String title = "My Title";
>>>
>>> public String getTitle() {
>>> return title;
>>> }
>>> }
>>>
>>> Example POM configuration:
>>>
>>> <configuration>
>>> <properties>
>>> <title>${project.name}</title>
>>> </properties>
>>> </configuration>
>>>
>>> There are more features, but this shows the core of it.
>>>
>>> Why such a plugin? The effect (accessing POM properties from Java) can
>>> also be achieved via resource
>>> filtering[
>>> http://blog.nigelsim.org/2011/08/31/programmatically-getting-the-maven-version-of-your-project/
>>> ].
>>> These are, in my opinion, the most significant advantages of either
>>> method.
>>>
>>> Advantages of the resource filtering method:
>>>
>>> * project requires no additional dependencies
>>>
>>> Advantages of using the plugin:
>>>
>>> * most of the work (and error checking) is done at build time, rather
>>> than run time; this is safer and more resource efficient
>>>
>>> * reduces the amount of boiler plate code; project specific Java code
>>> is generated, the author only writes a plugin configuration in the POM
>>>
>>> Any comments would be appreciated!
>>>
>>> Best regards,
>>> Wouter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
