I'm thinking we need some jira tickets here to keep track of this... or do they already exist? (Too lazy to check....)
/Anders On Tue, May 28, 2013 at 12:05 PM, Stephen Connolly < [email protected]> wrote: > 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 ! >> > >
