inline > From: Scott Comer (sccomer) > > Rick Bolkey (rbolkey) wrote: > > Hi all, > > > > > > > > So I've been developing an etch plugin for maven. There are a few > use > > cases I had in mind in developing the plugin, so I would like to > present > > those as well as go over the general flow of the plugin. I'd > appreciate > > some feedback as far as alternative use-cases that could fit within > the > > scope of the plugin. > > > > > > > > I had two use cases directly in mind. > > > > > > > > 1) A user has an etch file in their project, and wants to > generate > > a binding. > > > a client or a service implementation? > > 2) A user has a dependency containing an etch file, and wants to > > generate a binding. > > > a reference client or service?
The plugin wraps all the command line parameters to the compiler, so I believe that would be determined on the "what" parameter, unless I'm not understanding the difference. > so what is the different action between these two? Isn't a different action between the two use cases, step 2 below handles them unseen (resolving to the a file within the project vs inside the sandbox. > > > > > > Use case #2 service the case if you want to publish an etch file in > an > > artifact, and allow different projects to generate binding for it. > > > > > > > > Right now the plugin consists of one goal that does the following: > > > > > > > > 1) Scans through all the compile time dependencies of a project. > > If a dependency contains an etch file, that file along with any "txt" > > files (for inclusions) are extracted to a temporary sandbox under the > > target directory. > > > > 2) Plugin then looks for the etch file specified in the plugin > in > > the following locations. 1) as an absolute reference, 2) in > > "src/main/etch", and 3) in the sandbox where we extracted all the > found > > etch files. > > > > 3) Generate the binding based on the resolved etch file. > > > > > > > > I think I would like to separate steps 1 and 2 above into separate > > goals. Also, the plugin currently suppresses generation when it > detects > > the binding has already been generated (this can be overridden using > a > > "force" parameter. > > > not sure what you mean here. when / why would you want to suppress? More of a speed concern. I noticed that my IDE was running the Maven pre-compile lifecycles whenever I would refresh the project. The plugin is bound to the generate-sources lifecycle (just like the javacc-maven-plugin). So, I wanted a way to avoid having to scan through all the artifacts and generate a binding every time I refreshed the project, but I figured a 'force' parameter would be good to allow the developer the option if they want that to happen.
